4 ms·

Just out of curiosity, have you used any of these specific architectures on any real world projects and failed? If so, would you mind sharing your experience?

Just out of curiosity, have you used any of these specific architectures on any real world projects and failed? If so, would you mind sharing your experience? I'm currently reading up on DDD and thus far one of the main goals is to reduce complexity so you can easily reason about the software (reduce the mental load, understand the domain). Though I'm still in the early chapters of the book, thus far it has constantly reinforced this idea via layered architecture, modularizing code, aggregates, etc. There's nothing DDD specific about these ideas. I believe DDD is just about proper OO design.

charlieflowers 13y ago
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.

charlieflowers 13y ago

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.