4 ms·

Thanks for posting this, as I was going to do write more or less the same thing. Over the years (nearing two decades at this point) I've increasingly put empha

by enjo 13y ago

Thanks for posting this, as I was going to do write more or less the same thing. Over the years (nearing two decades at this point) I've increasingly put emphasis on reducing complexity, instead of increasing flexibility (which is what most "architectures" aim to do). Software doesn't fall down (usually) because of a lack of flexibility. It falls down because it becomes nearly impossible to reason about the system as it becomes more complex. In the old days we adopted this idea that refactoring code was always going to be nearly impossible. So we used plugins, really insane separations of concerns, and lots of decoration all to combat that boogeyman. All at the cost of any hope of building a sensible mental model out of our systems. It's not that "architecture" is bad per-se, it's just that most of these approaches create instant complexity and it's just not needed (usually). Instead finding sensible patterns and taking advantage of simple language-level constructs to maximize reusability are the only tools you really need.

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

by enjo 13y ago

nogridbag 13y ago

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.