3 ms·

So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architect

by tinco 5y ago

So this is a very fundamental explanation of DDD, the kind you might learn at university. But the last time I researched DDD there was a very concrete architecture associated with it, and I didn't really understand why. Every DDD article would also introduce CQRS for some reason, it seems they are inextricably connected, at least for web application development. Anyone got a good story on that?

dm3 5y ago
Unfortunately there isn't a single definition of DDD accepted by everyone. At its core DDD is about the practice of software design which puts Domain - user language and problems - first. There are no technical considerations. ES (Event Sourcing) and CQRS are technical patterns people like to use while doing DDD because of various reasons, but they're in no way required to practice DDD.
- mhd 5y ago
  I've seen architecture presentation where it seemed like event sourcing took DDD hostage, just using it as a vehicle to sell that particular astronaut-ism. Not even a ubiquitous language...
  - berkes 5y ago
    I think part of the reason is that event-sourced needs DDD. So any story or presentation about ES, will at least mention DDD. But DDD, by no means, needs ES. Another part of the reason, I think, is because many other architectural patterns have taken certain concepts 'hostage'. Take for example Rails. MVC. 'Model' in Rails has a clear and distinct meaning, place and implementation. There is no way to have a bounded context, isolated domain models in Rails, without at least the terminology becoming very confusing. Having root aggregates in Rails makes all that worse, even. What I'm trying to paint, here, is that ES naturally embraces DDD, whereas other architectures often conflict, or require effort to fit in DDD. Therefore, you'll probably find many talks about ES or CQRS and DDD, but hardly any about Actor, MVC, etc., and DDD.
- jrochkind1 5y ago
  Can anyone make explicit some of the "various reasons" ES/CQRS are associated with DDD? This is confusing me. To those experienced in DDD: You can do DDD without CQRS? And you can do CQRS without it being DDD too? This is not clear to me as an observer.
raducu 5y ago
DDD is sort of the OOP of OOP, without the clever Design Patterns. -- DDD is the kind of principles most OOP people can learn and apply in the same mechanistic way the apply OOP principles and that actually do pay off (unlike design patterns which are really clever but have very little impact in real world). CQRS is associated with DDD because it is the kind of smart pattern made out of bits that the other smart patterns frown against -- like data duplication/denormalization.
ToJans 5y ago
I think the definition of DDD is abstract on purpose. I proposed a one-liner a couple of years ago [0]: * The essence of DDD: make the implicit explicit (language, boundaries, code) and evolve your model so it matches the domain * But to be honest, in hindsight I think it was nothing more than a drip in the ocean, and does not clarify a lot, unless you are already well versed in DDD; it's like those explanations about monads... As for the CQRS-as-a-top-level architecture: There are a lot of "beginner experts" and self-proclaimed thought leaders emerging, as DDD is getting more popular... (~= Agile movement) CQRS-all-the-things is typically a phase that you go through if you are studying DDD. (I've been there, done that, got the T-shirt.) In my personal opinion a good heuristic to detect "beginner experts" is that they prefer to use a lot of DDD lingo, and focus on the more technical aspects instead of truly trying to understand the business domain first. Update: Added the first paragraph with an attempt for a DDD definition. [0] https://tojans.me/posts/ddd-in-a-tweet/ https://tojans.me/posts/ddd-in-a-tweet/
macando 5y ago
It's because a popular book on DDD "Implementing Domain-driven Design" uses CQRS in its examples. If the book was written today CQRS would probably be replaced with Serverless computing or something even more trendy.
amw-zero 5y ago
I'm not advocating for CQRS or any of that, I've personally never used it on a project. But, the reason that architectures are associated with DDD is that DDD is fundamentally a philosophy or an idea. Certain software designs achieve that philosophical ideal better than others. For example, DDD stresses the idea of an "isolated domain model" - and that has a very practical reason, being that your business rules are already complicated enough so mixing in database transactions, HTTP caching, response serialization, authorization, etc. etc., into your domain logic makes it harder to understand. You want to be able to have a conversation with a customer / domain expert where they explain something and you can adjust the code quickly to meet their needs. That's the ideal goal at least. So some patterns enable that goal better. For example, this implies that you need some kind of data access layer pattern so that code that cares about the database is separate from code that cares about domain logic. Well, there's a million different ways to get that separation, and they have different tradeoffs, and like everything else, certain patterns become trendy. That's what's going on with CQRS. People feel that it leads to a better expression of the domain model, because creating data and querying it are often radically different from the customer's perspective. Whether or not that goal is achieved, I'm not sure. But that's the reason people are experimenting with patterns like that, as I see it.

by tinco 5y ago

dm3 5y ago

Unfortunately there isn't a single definition of DDD accepted by everyone. At its core DDD is about the practice of software design which puts Domain - user language and problems - first. There are no technical considerations. ES (Event Sourcing) and CQRS are technical patterns people like to use while doing DDD because of various reasons, but they're in no way required to practice DDD.

mhd 5y ago
I've seen architecture presentation where it seemed like event sourcing took DDD hostage, just using it as a vehicle to sell that particular astronaut-ism. Not even a ubiquitous language...
- berkes 5y ago
  I think part of the reason is that event-sourced needs DDD. So any story or presentation about ES, will at least mention DDD. But DDD, by no means, needs ES. Another part of the reason, I think, is because many other architectural patterns have taken certain concepts 'hostage'. Take for example Rails. MVC. 'Model' in Rails has a clear and distinct meaning, place and implementation. There is no way to have a bounded context, isolated domain models in Rails, without at least the terminology becoming very confusing. Having root aggregates in Rails makes all that worse, even. What I'm trying to paint, here, is that ES naturally embraces DDD, whereas other architectures often conflict, or require effort to fit in DDD. Therefore, you'll probably find many talks about ES or CQRS and DDD, but hardly any about Actor, MVC, etc., and DDD.
jrochkind1 5y ago
Can anyone make explicit some of the "various reasons" ES/CQRS are associated with DDD? This is confusing me. To those experienced in DDD: You can do DDD without CQRS? And you can do CQRS without it being DDD too? This is not clear to me as an observer.

raducu 5y ago

DDD is sort of the OOP of OOP, without the clever Design Patterns. -- DDD is the kind of principles most OOP people can learn and apply in the same mechanistic way the apply OOP principles and that actually do pay off (unlike design patterns which are really clever but have very little impact in real world). CQRS is associated with DDD because it is the kind of smart pattern made out of bits that the other smart patterns frown against -- like data duplication/denormalization.

ToJans 5y ago

I think the definition of DDD is abstract on purpose. I proposed a one-liner a couple of years ago [0]: * The essence of DDD: make the implicit explicit (language, boundaries, code) and evolve your model so it matches the domain * But to be honest, in hindsight I think it was nothing more than a drip in the ocean, and does not clarify a lot, unless you are already well versed in DDD; it's like those explanations about monads... As for the CQRS-as-a-top-level architecture: There are a lot of "beginner experts" and self-proclaimed thought leaders emerging, as DDD is getting more popular... (~= Agile movement) CQRS-all-the-things is typically a phase that you go through if you are studying DDD. (I've been there, done that, got the T-shirt.) In my personal opinion a good heuristic to detect "beginner experts" is that they prefer to use a lot of DDD lingo, and focus on the more technical aspects instead of truly trying to understand the business domain first. Update: Added the first paragraph with an attempt for a DDD definition. [0] https://tojans.me/posts/ddd-in-a-tweet/ https://tojans.me/posts/ddd-in-a-tweet/

macando 5y ago

It's because a popular book on DDD "Implementing Domain-driven Design" uses CQRS in its examples. If the book was written today CQRS would probably be replaced with Serverless computing or something even more trendy.

amw-zero 5y ago

I'm not advocating for CQRS or any of that, I've personally never used it on a project. But, the reason that architectures are associated with DDD is that DDD is fundamentally a philosophy or an idea. Certain software designs achieve that philosophical ideal better than others. For example, DDD stresses the idea of an "isolated domain model" - and that has a very practical reason, being that your business rules are already complicated enough so mixing in database transactions, HTTP caching, response serialization, authorization, etc. etc., into your domain logic makes it harder to understand. You want to be able to have a conversation with a customer / domain expert where they explain something and you can adjust the code quickly to meet their needs. That's the ideal goal at least. So some patterns enable that goal better. For example, this implies that you need some kind of data access layer pattern so that code that cares about the database is separate from code that cares about domain logic. Well, there's a million different ways to get that separation, and they have different tradeoffs, and like everything else, certain patterns become trendy. That's what's going on with CQRS. People feel that it leads to a better expression of the domain model, because creating data and querying it are often radically different from the customer's perspective. Whether or not that goal is achieved, I'm not sure. But that's the reason people are experimenting with patterns like that, as I see it.