I've seen projects that regretted going down those roads. I can't say they failed because of it (sad truth be told, several of them failed because they were in

I've seen projects that regretted going down those roads. I can't say they failed because of it (sad truth be told, several of them failed because they were in such a dysfunctional corporate environment that they were doomed before the project even started). CQRS can go wrong if you try to do only 90% of it instead of 100% of it. A crude analogy: consider a nation choosing to change the side of the road its cars drive on. So the US wants to switch over to driving on the left. Well, it pretty much needs to be a universal switch, or there are going to be ugly problems. CQRS is sort of like that. It changes so many assumptions that "percolate" through the whole architecture, that it's pretty much an all or nothing thing. So if there is any dissension amongst the team, you're likely to end up in a 90% (or less) situation and start having problems. Plus, CQRS is complex, especially if you try to do it with a relational database. And the complexity is something you will have to carry, and it will weigh you down. (The ever-present caveat -- there are situations where CQRS can be a good approach). DDD is interesting. It has so much appeal to it. Parts of it almost read like developer-porn. And there is a lot of wisdom there. However, it too brings complexity. It is not "the simplest thing that could possibly work." Rather, it suggests you and your team really invest some mental cycles projecting the future and trying to design a domain object model that will suit your business for a long time. That analysis could be valuable. It's hard to argue that thinking ahead is a bad idea. However, many teams, in the process of performing that deep DDD analysis, have lost their way and gone overboard with unnecessary complexity. Maybe the flaw is with developers' innate vulnerability to the siren song of complexity moreso than with DDD itself. And I'm sure many have succeeded with DDD. But many teams have lost their way with it too, and usually by letting complexity get out of hand.