19 ms·

I've got someone on my team who's a huge advocate for DDD, but can't explain it very well. So I've been diving into the literature on it, and I can absolutely +

I've got someone on my team who's a huge advocate for DDD, but can't explain it very well. So I've been diving into the literature on it, and I can absolutely +1 the "not dead-simple" bit. Then again, it could just be the obscure terminology. Every time I read about it, I keep thinking "there's probably a much easier way to explain this" and it's frustrating. So much jargon.

Twisol 6y ago
> Every time I read about it, I keep thinking "there's probably a much easier way to explain this" and it's frustrating. That's my sentiment, too. The descriptions I've seen give primacy to the code-related patterns, like "Aggregate" and "Entity", but increasingly I think they're the result of applying DDD, not the starting point. (And, as oft noted, they arise in a distinctly-flavored OOP context which has fallen somewhat out of favor.) My team has had to pick things up as we go, but we have the benefit(?) of a complex domain, so we worked our way backwards to first principles anyway. The most important part, we've found, is that someone on the team has to be a domain expert, and anyone planning/designing/architecting features must be an expert at least in the aspects they are working on. The reason is simple, if daunting: software is automation, and we are ultimately automating a domain process that would be undertaken, at least in principle, by a human. If we are to tell a machine what to do, we must understand the process at least as well as the human who would undertake it -- and potentially more so. It simply doesn't make sense to have a non-expert team build a supposedly-expert system. (This is of course why "the customer" is such an important part of an Agile team. Sometimes the customer's expertise is enough, by proxy, to effectively design a software-based solution. But even then, that expertise gets processed by somebody into software-oriented tasks.) Since our domain is particularly complex, we've found it valuable to distill our knowledge of the domain into a "domain model" document. This makes sure that there's a single source of truth for domain understanding on the team, which keeps things from otherwise getting too out-of-sync. It's particularly valuable to assign a single editor to that document, to maintain cohesion across the model. The key point about a domain model is that it does not describe a particular software solution, and should not be especially biased toward the needs of software. On the other hand, it should organize the domain in ways that reduce redundancy, capture similarities and differences, etc. Put differently, software engineering is a domain of its own, and we should be able to bring our experience with abstraction and modularity to bear. Whether explicit (documented) or implicit (known by experts), a domain model should illuminate the global structure of the domain. Boundaries between parts of the domain should start to become visible, and the relationships across those boundaries speak to the ownership and flow of information. This is where DDD "bounded contexts" emerge, and where the so-called "ubiquitous language" becomes meaningful. The domain model doesn't solve a problem, but it brings it much closer to the software engineering domain, and makes it much more tractable to use prototypes to identify gaps in the model or to try different approaches to automating different domain processes. It should be much easier to get a birds-eye view of how the whole system behaves, even before software enters the picture.
mattferderer 6y ago
Coding Blocks is a podcast that has a nice intro series on DDD - https://www.codingblocks.net/podcast/why-domain-driven-design/ https://www.codingblocks.net/podcast/why-domain-driven-desig... They call out terminology as 1 of the most confusing parts of DDD. I think they do a good job of discussing it though in an easy & empathetic way. Pluralsight has a nice DDD Learning path which has 2 popular & recommended courses in the above podcast, "Domain-Driven Design Fundamentals" & "Modern Software Architecture: Domain Models, CQRS, and Event Sourcing". You're probably familiar already with the books "Domain-Driven Design: Tackling Complexity in the Heart of Software" & "Domain-Driven Design Distilled".

Twisol 6y ago

> Every time I read about it, I keep thinking "there's probably a much easier way to explain this" and it's frustrating. That's my sentiment, too. The descriptions I've seen give primacy to the code-related patterns, like "Aggregate" and "Entity", but increasingly I think they're the result of applying DDD, not the starting point. (And, as oft noted, they arise in a distinctly-flavored OOP context which has fallen somewhat out of favor.) My team has had to pick things up as we go, but we have the benefit(?) of a complex domain, so we worked our way backwards to first principles anyway. The most important part, we've found, is that someone on the team has to be a domain expert, and anyone planning/designing/architecting features must be an expert at least in the aspects they are working on. The reason is simple, if daunting: software is automation, and we are ultimately automating a domain process that would be undertaken, at least in principle, by a human. If we are to tell a machine what to do, we must understand the process at least as well as the human who would undertake it -- and potentially more so. It simply doesn't make sense to have a non-expert team build a supposedly-expert system. (This is of course why "the customer" is such an important part of an Agile team. Sometimes the customer's expertise is enough, by proxy, to effectively design a software-based solution. But even then, that expertise gets processed by somebody into software-oriented tasks.) Since our domain is particularly complex, we've found it valuable to distill our knowledge of the domain into a "domain model" document. This makes sure that there's a single source of truth for domain understanding on the team, which keeps things from otherwise getting too out-of-sync. It's particularly valuable to assign a single editor to that document, to maintain cohesion across the model. The key point about a domain model is that it does not describe a particular software solution, and should not be especially biased toward the needs of software. On the other hand, it should organize the domain in ways that reduce redundancy, capture similarities and differences, etc. Put differently, software engineering is a domain of its own, and we should be able to bring our experience with abstraction and modularity to bear. Whether explicit (documented) or implicit (known by experts), a domain model should illuminate the global structure of the domain. Boundaries between parts of the domain should start to become visible, and the relationships across those boundaries speak to the ownership and flow of information. This is where DDD "bounded contexts" emerge, and where the so-called "ubiquitous language" becomes meaningful. The domain model doesn't solve a problem, but it brings it much closer to the software engineering domain, and makes it much more tractable to use prototypes to identify gaps in the model or to try different approaches to automating different domain processes. It should be much easier to get a birds-eye view of how the whole system behaves, even before software enters the picture.

mattferderer 6y ago

Coding Blocks is a podcast that has a nice intro series on DDD - https://www.codingblocks.net/podcast/why-domain-driven-design/ https://www.codingblocks.net/podcast/why-domain-driven-desig... They call out terminology as 1 of the most confusing parts of DDD. I think they do a good job of discussing it though in an easy & empathetic way. Pluralsight has a nice DDD Learning path which has 2 popular & recommended courses in the above podcast, "Domain-Driven Design Fundamentals" & "Modern Software Architecture: Domain Models, CQRS, and Event Sourcing". You're probably familiar already with the books "Domain-Driven Design: Tackling Complexity in the Heart of Software" & "Domain-Driven Design Distilled".