3 ms·

DDD technical patterns are a weird bunch. On one hand, there are quite a few smart concepts in there. Everyone should know what aggregates are, for example. O

DDD technical patterns are a weird bunch. On one hand, there are quite a few smart concepts in there. Everyone should know what aggregates are, for example. On the other hand, many of them have little to do with the basic premise of DDD. You can have DDD without these specific patterns. On the third hand, people start applying every single pattern everywhere, like they did with GoF patterns.

rapnie 5y ago
I'd advice people new to DDD to involve themselves with understanding the Strategic Design parts first. The rationale, pros and cons for using it etc. And stay well away from tactical patterns until you know the role of DDD wrt the objectives you want to achieve. Strategic vs. tactical are completely different concerns. The problem with a lot of DDD information is that people tend to dive into tactical way to early and introduce all kinds of architecture that is not needed. Note that result of strategic analysis may well be to conclude that a simple CRUD design is the best way forward (for a subdomain or even the entire project). The non-technical domain understanding is most important, and also helps heaps in keeping your (non-technical) stakeholders in the loop throughout the development process.
- discreteevent 5y ago
  I found this book very good in that regard. The first half of the book is on strategy and emphasizes its importance. It also makes it clear that only a subset of your system is suitable for DDD (for example, not the CRUD bits). I also found it much clearer and less verbose than the Evans book. https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Practices+of+Domain+Driven+Design-p-9781118714706 https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...
  - kqr 5y ago
    Yes, this is a very good introduction to DDD proper, with the primary focus on when to apply what parts of it!
marcosdumay 5y ago
> On the other hand, many of them have little to do with the basic premise of DDD. Honestly, I see no relation at all. Those technical patterns can be applied the same way whether you model your code after the domain or not, and you don't need them at all to model your code after the domain. They look a lot like "true Agile" 2.0.

rapnie 5y ago

I'd advice people new to DDD to involve themselves with understanding the Strategic Design parts first. The rationale, pros and cons for using it etc. And stay well away from tactical patterns until you know the role of DDD wrt the objectives you want to achieve. Strategic vs. tactical are completely different concerns. The problem with a lot of DDD information is that people tend to dive into tactical way to early and introduce all kinds of architecture that is not needed. Note that result of strategic analysis may well be to conclude that a simple CRUD design is the best way forward (for a subdomain or even the entire project). The non-technical domain understanding is most important, and also helps heaps in keeping your (non-technical) stakeholders in the loop throughout the development process.

discreteevent 5y ago
I found this book very good in that regard. The first half of the book is on strategy and emphasizes its importance. It also makes it clear that only a subset of your system is suitable for DDD (for example, not the CRUD bits). I also found it much clearer and less verbose than the Evans book. https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Practices+of+Domain+Driven+Design-p-9781118714706 https://www.wiley.com/en-us/Patterns%2C+Principles%2C+and+Pr...
- kqr 5y ago
  Yes, this is a very good introduction to DDD proper, with the primary focus on when to apply what parts of it!

marcosdumay 5y ago

> On the other hand, many of them have little to do with the basic premise of DDD. Honestly, I see no relation at all. Those technical patterns can be applied the same way whether you model your code after the domain or not, and you don't need them at all to model your code after the domain. They look a lot like "true Agile" 2.0.