News for hackers. Stuff that matters.
Re:Domain-Driven Design by orthoxerox on Monday September 27, 2021 @04:42AM (#28668458)
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.

Re:Domain-Driven Design by rapnie on Monday September 27, 2021 @05:08AM (#28668601)
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.
Re:Domain-Driven Design by discreteevent on Monday September 27, 2021 @07:06AM (#28669258)
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+Pr...

Re:Domain-Driven Design by kqr on Monday September 27, 2021 @08:53AM (#28670066)
Yes, this is a very good introduction to DDD proper, with the primary focus on when to apply what parts of it!
Re:Domain-Driven Design by marcosdumay on Monday September 27, 2021 @06:23AM (#28669027)
> 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.