903 karma · joined January 17, 2008
Is an accurate description of a large number of products that I have been forced to use after various CTOs have played golf with a vendors sales team.
CQRS doesn't force you to build a distributed system. It doesn't make you use eventual consistency or asynchrony but provides them as options.
For example the system I worked on had synchronous command handling with a mixture of synchronous and asynchronous subscribers. This allowed us to use eventual consistency where it was appropriate and for all clients to be immediately aware of problems.
I found the cognitive load to be less than with other service based architectures I have worked on. I could jump into any area of the code base and because of the naming conventions for commands and events I could see what was going on - this has never been my experience with a service oriented architecture.
The main change in developer thinking that is necessary is that you don't record state you record state transitions. Once that is internalised development is easy, a new feature requires new commands and handlers, new events, new queries and an updates to aggregates.
I had absolutely no problem with cross cutting concerns - security for example was handled in command handlers where needed. Other system components of our system that didn't use CQRS - for example reporting, general ledger, third party integrations - received data from the event stream and injected commands back into the system. So in no way was our organisation infected by CQRS / ES.
Kotlin worked well - clear concise code, no null worries and no cast worries.
It is peculiarly refreshing to know that my code won't even compile if I try to call a method on null and that Intellij will underline the code in red and suggest a fix.
At the time I was using it I would say the quality of some of the code in the Kotlin API was questionable - specifically the jdbc code. I used the parts that seemed sensible and wrote additional code to provide the functionality I needed. I don't think that code is even in the standard API anymore.
Random annoyances off the top of my head - you can't necessarily understand an isolated function unless you know what implicits are being used, crazy overuse of operator overloading and slow compilation times (this has improved over the years).
You don't have to learn Scala, you could learn Clojure, F#, OCaml or Haskell. They would all teach you interesting aspects of programming and then you could come back and examine Scala with a broader perspective.
This appears to be very similar to the last amendment although not identical. They withdrew the previous amendment last week.
Earlier submission here - https://news.ycombinator.com/item?id=8036515
Annotations in Java have always bothered me! Why are they needed? I don't need them in Clojure, Go, Haskell, C - similar behaviour is supplied by alternative means.
With plain functions if I need to wrap requests or responses I just wrap the functions. With JAX-RS I need to find or write an appropriate annotation or start adding filters.
With plain functions I can share behaviour between resources by sharing functions.
and I like it that way