Patterns, Principles, and Practices of Domain-Driven Design

Domain Modeling is hard. Teaching & presenting about Domain Modeling is even harder (I've tried it, honest word). Writing a *good* book about Domain Modeling is ninja-level challenge. And fortunately PPPofDDD is a *good* book about Domain Modeling. Maybe it's more 4.5 stars than 5, but I still believe it's more 5 than 4. Why? 1.) Author does not try to re-tell The Blue Book. I really, really had the honest feeling that his greatest intention was to show how do you use DDD principles while building actual systems. Not just on line-of-code level. And what's important, I think he did it well, at least clearly better than VV in Red Book. 2.) It's quite easy to write about desing in a boring way: either because you being too abstract (only conceptual notions) or to specific (by diving deep into the examples you readers do not give an f-word). But to be honest this book is not boring -> maybe it's author's writing style. Anyway, this book is in general more pleasant to read (& more engaging) than both Blue and Red Book. 3.) There are plenty of references (incl. all examples) to .NET! ;) Ok, it may not be a Pro for everyone, but I appreciate it. 4.) Part IV (which I initially expected a total shit & 'space-filler') appeared to be the best part of the book - very practical & pragmatic. Even if I don't necessarily agree with all the statements (or rather - with some I agree with 'yes, but ...' suffix :>), I really like all the thoughts gathered in such a clear & approachable way. 5.) Any specific points made I've found useful? Yes, some about composability (bounded context & dependencies between them), state pattern & lazy loading. Cons? Yes, some: 1.) They were at least few examples that didn't really add much value - either too obvious or too bloated (what makes me feel they miss the point or don't have any). 2.) Chapters 9 & 10 are surprisingly shallow. I've kinda expected more. Fortunately book compensates it later. To summarize: it's a very good book about DDD. It doesn't change the fact that you're supposed to read Blue Book first anyway. But if you're about to choose whether read this one or Red Book ("Implementing DDD"), I believe that PPPofDDD is a better choice.

This is one of those rare, stellar software books where it's evident that great care and attention was lavished in preparing it. Profusely illustrated, clearly articulated, replete with marvelous end-of-chapter summaries, this book is a keeper. I'm a Java / Scala programmer, working in the Big Data area, and would have preferred the code examples to be in either of these languages. But I must confess that the C# code is pristine enough in its quality that it it's easy to follow along. The content and crystal-clear presentation is abundantly evident throughout, though I feel compelled to point out two stand-out chapters that are not to be missed: "Chapter 21: Repositories Repositories mediate between the domain model and the underlying data model. They ensure that the domain model is kept separate from any infrastructure concerns." "Chapter 24: CQRS: An Architecture of a Bounded Context CQRS is a design pattern that creates two models where there once was one. Instead of a single model to handle the two different contexts of reads and writes, two explicit models are created to handle commands or serve queries for reports." All-in-all, a terrific and delightful book, which is why I think of it as one of the two definitive DDD books, the other one being, of course, the seminal volume by Eric Evans himself (the classic book titled "Domain-Driven Design: Tackling Complexity in the Heart of Software")!

Not a true reference book, the subject is too much art to be metric science. Still, this is good for techniques and hints to refer back to from time to time.

I have not read the other big books on domain driven design, so I cannot compare them, however I found this book extremely well written and easy to follow. After first watching the PluralSight training, I came away with a bit of theoretical knowledge and a ton of questions -- and this book answered a ton of them. I would start off a bit puzzled at how all the pieces fit together, and then a sentence or example or diagram would bring it all into place and suddenly so many more things would make sense. Really, really a great read. While there are some topics I wish were covered a bit more, or a bit differently, these are almost all topics that are much more specific to the domain space that I am working on and probably would have no place in the book. If you're just starting out like I was, read through this book, try out a practical example on your own, and do a lot of blog reading to fill in the specific gaps. I do recommend starting off by creating a completely independent project and not trying to fit it into any existing system that you have -- it's so easy early for existing technical problems to really overshadow the "domain" learning you're trying to do at that point.

I'm reading this book after Eric Evans Domain-Driven Design: Tackling Complexity in the Heart of Software. Patterns, Principles and Practices gives much more detailed and practical tips for implementing DDD in your projects, but I don't regret having read Evans book first, it gave a good foundation for absorbing ideas from this book. The examples are given in C#. Being a Ruby on Rails developer, at first I was afraid that they would be no use to me. But the concepts are universal for any programming platform, and code examples are easy to follow and translate. I highly recommend this book to anyone who wants to implement DDD in their projects.

Perfect!

Anche se ha i suoi anni rimane una pietra miliare

Excellent livre, qui commence par 5 chapitres de "généralités" sur le développement logiciel en équipe, pour poser les bases du travail entre développeur et expert de domaine, de multiples conseils pour arriver à se comprendre et mettre en place un langage commun, avant d'attaquer du plus concret niveau développeur. Anglais abordable, autant dans les exemples domaines que sur le technique

This is arguably the "Best Book" written on Domain Driven Design since the seminal book By Eric Evans. I have read both the Red Book and Blue Book. Both the books introduced the Domain Driven concepts and highlighted the salient features and patterns of Application Architecture and advocate the application of DDD patterns for handling complexity in the application domain analysis and application implementation design patterns for elegant solution designy. This books break it down further and shows the nitty gritty of actually applying the concepts introduced in the Red Book and the Blue Book using elaborate and in-depth examples and takes us through the steps of analysing the problem domain, understand and developing the UL and the process of domain analysis using the requirements laid down at the inception of the project. In the subsequent chapters the author provides ways of applying DDD principles using different architectural solution strategies and draws from his experiences to further explain by evaluating and comparing the pros and cons adopting different architectural styles and patterns in his examples. Though the examples are restricted to .NET and Microsoft Technology Stack, they are still easy to follow and understand the essence of applying DDD while designing a software application.

First of all, thank you Scott Millett. I started reading this book at the end of 2015 and I am right now on chapter eleven. It is not because of the complexity of this book. It is because of the essential knowledge shared in each sentence (ok, maybe only each paragraph ;-)). My approach right now is to read a page and practice it right away, either in the company at all, in the team or in the code. Since Domain Driven Design is quite close to normal behavior and life, I always run into open arms when explaining somebody an idea, either a part of the qa, the developers or the business stuff. It is also cool that Scott Millett tells you more than once, Domain Driven Design is not the silver bullet. As written above, I am far away from having finished this book, but even now (ore even few chapters before) I would have signed the sentence "totally worth the money". Last but not least, thank you Scott Millett.