| Congratulations on the release! My experience is that most supposed implementations of DDD are problematic because the focus is on the infrastructure, plumbing and implementation, rather than on the real challenge which is modeling a complex problem domain. This is the exact opposite of Evan’s intention as stated in his book. Because there is a general inability to model a complex system into an object model as is the basis of his book, focus falls onto programming constructs and things like “ubiquitous language” which pre-dates Evans and is self evident to most. About 80% of CQRS/event sourcing projects I review or consult on are unsuccessful. In most cases this is primarily due to them being applied where they shouldn’t be, by (inexperienced) teams viewing these techniques as “silver bullets” to success. I should note that I am mainly involved with line-of-business type systems, rather that projects focusing on computing infrastructure and the computing and data sciences, and therefore speak to the former. |
It is important to note that my book is not an alternative to "Domain-Driven Design" by Eric Evans. Rather, it is an introduction to DDD, an explanation of CQRS and Event Sourcing and an implementation guide. Also, it is not explaining how to approach and model complex domain problems. I wouldn't consider myself experienced in that. Everything I worked with so far was rather trivial.
I can very much relate to your experience with projects that applied CQRS and Event Sourcing. In fact, the longest project I worked on was a negative example. The patterns were used as part of the system architecture. Their use was never justified with any reason specific to the domain or the business. In the end, some parts of the system would have been better off with a completely different architecture.
I already have convinced project teams to not use Event Sourcing when they thought they needed it. Also, I often hear it being conflated with Event-Driven Architecture.