What do you think?
Rate this book
Professional Domain-Driven Design Patterns
Methods for managing complex software construction following the practices, principles and patterns of Domain-Driven Design with code examples in C#This book presents the philosophy of Domain-Driven Design (DDD) in a down-to-earth and practical manner for experienced developers building applications for complex domains. A focus is placed on the principles and practices of decomposing a complex problem space as well as the implementation patterns and best practices for shaping a maintainable solution space. You will learn how to build effective domain models through the use of tactical patterns and how to retain their integrity by applying the strategic patterns of DDD. Full end-to-end coding examples demonstrate techniques for integrating a decomposed and distributed solution space while coding best practices and patterns advise you on how to architect applications for maintenance and scale.Offers a thorough introduction to the philosophy of DDD for professional developersIncludes masses of code and examples of concept in action that other books have only covered theoreticallyCovers the patterns of CQRS, Messaging, REST, Event Sourcing and Event-Driven ArchitecturesAlso ideal for Java developers who want to better understand the implementation of DDD
432 pages, Kindle Edition
First published May 19, 2014
209 people are currently reading
1463 people want to read
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 41 reviews
June 14, 2015
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.
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.
July 16, 2016
PPPofDDD is similar to "Implementing Domain-Driven Design" book by Vaughn Vernon, although it presents the examples with .Net technologies. Both books give focus on bounded contexts and strategic design and they're more technical than Evans' DDD book, showing a lot of implementation details regarding bounded contexts integration with REST and messaging systems.
This book may be considered a "software book" or "software architecture book" because of its wide range of technical topics. The author wastes too much pages with small tutorials teaching how to implement some concept with different strategies and technologies. If you're only worried about DDD main topics, you may think this book is too much big and somewhat boring.
This book may be considered a "software book" or "software architecture book" because of its wide range of technical topics. The author wastes too much pages with small tutorials teaching how to implement some concept with different strategies and technologies. If you're only worried about DDD main topics, you may think this book is too much big and somewhat boring.
February 6, 2016
The very first book I've read on domain-driven design was Jimmy Nilsson's "Applying Domain-Driven Design and Patterns". I read that book in 2006, after which at the beginning of 2007 I read the blue book by Eric Evans for the first time. I had a lot of questions back in those days on the practicalities of the topics that Eric Evans explains in his book. The book that Jimmy Nilsson wrote was his view on domain-driven design and the things he learned from wrestling through the writings of Eric Evans. The next and last noteworthy effort in book form on this topic dated from 2012 when Vaughn Vernon released his take titled "Implementing Domain-Driven Design". This book, which I still have to get through, takes another practical stance on domain-driven design just as Jimmy Nilsson did for his book.
After I learned that Scott Millett had written a new book on domain-driven design, he was so kind to sent me a copy. I was very eager to pick it up and read it. And I'm very glad I did. This book can be regarded as the current state of affairs when it comes to domain-driven design. Scott took the right approach by first discussing the strategic patterns before the tactical patterns. What I personally like is how Scott kindly builds up knowledge with the reader, bringing back and repeating topics from previous chapters and also pointing to next chapters, pointing out how things relate and influence each other. The book read as a story, slowly building up knowledge.
As already mentioned, the first part of the book discusses the strategic patterns of domain-driven design. The chapters that explain the tactical patterns are richly illustrated with lots of code. What I particularly like is how Scott informs the reader by showing different implementations and clearly discussing their advantages and disadvantages. This unopinionated approach is quite refreshing. I particularly liked the chapter about domain events, where several approaches are touched and explained. However, I did not care a lot about the chapter on repositories where I found it to have too much code listings that were too long for my taste. The last part of the book also touches on topics like CQRS and event sourcing.
I'm a slow reader, so it took me quite a while to get through it. But it was definitely worth turning over all 736 pages. I learned a lot of new things and also relearned some known things. This is a perfect book for developers who are new to domain-driven design and want to learn what it's all about. But also developers who are more experienced when it comes to domain-driven design can benefit a great deal by reading this book. Highly recommended!
After I learned that Scott Millett had written a new book on domain-driven design, he was so kind to sent me a copy. I was very eager to pick it up and read it. And I'm very glad I did. This book can be regarded as the current state of affairs when it comes to domain-driven design. Scott took the right approach by first discussing the strategic patterns before the tactical patterns. What I personally like is how Scott kindly builds up knowledge with the reader, bringing back and repeating topics from previous chapters and also pointing to next chapters, pointing out how things relate and influence each other. The book read as a story, slowly building up knowledge.
As already mentioned, the first part of the book discusses the strategic patterns of domain-driven design. The chapters that explain the tactical patterns are richly illustrated with lots of code. What I particularly like is how Scott informs the reader by showing different implementations and clearly discussing their advantages and disadvantages. This unopinionated approach is quite refreshing. I particularly liked the chapter about domain events, where several approaches are touched and explained. However, I did not care a lot about the chapter on repositories where I found it to have too much code listings that were too long for my taste. The last part of the book also touches on topics like CQRS and event sourcing.
I'm a slow reader, so it took me quite a while to get through it. But it was definitely worth turning over all 736 pages. I learned a lot of new things and also relearned some known things. This is a perfect book for developers who are new to domain-driven design and want to learn what it's all about. But also developers who are more experienced when it comes to domain-driven design can benefit a great deal by reading this book. Highly recommended!
May 10, 2017
It's done. The nightmare is over. This is the driest book I have read in a while. There is a ton of useful information but you have to get through a lot of pain to get it. I found it immensely useful for architecture design but it is not for the faint of heart.
February 8, 2016
Rating 3.5/5
As a technical book, I was expecting it to be more precise and hitting the target.
But here and there it turned out to be too much of story telling. (at-least in the first part of the book).
It may act as an advantage to read this and follow all of the steps if and only if
- the stakeholder gives sufficient money to invest time into this.
- if the project appears to be from scratch and you need all of the best practices to be a part of the recipe.
I really liked Part 3 and 4, those were what impressed me, we often don't get enough time and money to involve in a project from scratch (esp considering I am from India).
I read this book only looking at specific chapters, so there are chances this review is biased!
As a technical book, I was expecting it to be more precise and hitting the target.
But here and there it turned out to be too much of story telling. (at-least in the first part of the book).
It may act as an advantage to read this and follow all of the steps if and only if
- the stakeholder gives sufficient money to invest time into this.
- if the project appears to be from scratch and you need all of the best practices to be a part of the recipe.
I really liked Part 3 and 4, those were what impressed me, we often don't get enough time and money to involve in a project from scratch (esp considering I am from India).
I read this book only looking at specific chapters, so there are chances this review is biased!
This entire review has been hidden because of spoilers.
June 14, 2019
to long. not enough explanations why something is better or worse. Nice 'Salient Points' in each chapter
May 24, 2020
Amazing book.
Highly pedagogical thanks to the tones of code and examples that come with the theory, which is the main asset of the book, from my point of view.
Also very complete, getting a little bit into CQRS and ES (Event Sourcing).
Highly recommended for anyone who wants to get deeper into DDD and see other people approaches.
Highly pedagogical thanks to the tones of code and examples that come with the theory, which is the main asset of the book, from my point of view.
Also very complete, getting a little bit into CQRS and ES (Event Sourcing).
Highly recommended for anyone who wants to get deeper into DDD and see other people approaches.
July 27, 2016
Very pragmatic and down-to-earth exposure to DDD. Mixes in right volume theory and examples. Much easier to read than similar work on DDD by Vernon Vaugn. A big plus is that the author reflected on many of the modern tendencies in application architecture (CQRS, Event Sourcing, REST etc.).
February 1, 2025
There is irony in that the parts of the book which the author means as most important are written worse than other parts. In the 'Principles and Practices' and 'Strategic patterns' parts the amount of repetitions is overwhelming. How many times has the author mentioned that DDD should be applied only for core contexts, and only for complex enough ones? Maybe 6-7... At some point I started scrolling down all the repetitions.
'Strategic patterns' part is devoted to the topic which is although related to the DDD (well, in applications and solutions design pretty everything is related), but perhaps belongs more to infrastructure and architecture design. And if one touches this topic, there is much more there than distinguishing between RPC and REST, or synchronous vs asynchronous communication. This part looked a bit shallow to me and not convincing that it should be in this book. I would recommend another book which explores the topic of distributed architecture much deeper: "Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures https://www.goodreads.com/book/show/5...
Other parts - Tactical patterns and Design patterns for effective applications - were actually quite good. Very nice and deep explanation of value objects, entities, aggregates and domain services. The latter ones are usually touched very briefly if at all in various blogs. Here they've got deserved attention. Also the book presents a few solutions for implementation of domain events, quite good overview of event-sourcing and CQRS.
The book could have been a bit better with a good editor. Language sometimes looks very untidy. Here's an example:
"Architectures are bounded context and not application specific. The architect for a simple bounded context with low complexity could be composed of a combination of a layered design with the transaction script pattern for the domain layer."
Architectures are bounded context? What does that mean? Or did he want to say that architectures are specific to bounded context but not to application? His words order looks like a programming code not like a human language (well, professional deformation perhaps, I understand). And then in the next sentence: "The architect for ... could be composed..." Did he want to say 'the architecture'? I know, this looks like a stupid typo. But such a language in two sentences one after another... And there are more of such examples.
'Strategic patterns' part is devoted to the topic which is although related to the DDD (well, in applications and solutions design pretty everything is related), but perhaps belongs more to infrastructure and architecture design. And if one touches this topic, there is much more there than distinguishing between RPC and REST, or synchronous vs asynchronous communication. This part looked a bit shallow to me and not convincing that it should be in this book. I would recommend another book which explores the topic of distributed architecture much deeper: "Software Architecture: The Hard Parts: Modern Trade-Off Analyses for Distributed Architectures https://www.goodreads.com/book/show/5...
Other parts - Tactical patterns and Design patterns for effective applications - were actually quite good. Very nice and deep explanation of value objects, entities, aggregates and domain services. The latter ones are usually touched very briefly if at all in various blogs. Here they've got deserved attention. Also the book presents a few solutions for implementation of domain events, quite good overview of event-sourcing and CQRS.
The book could have been a bit better with a good editor. Language sometimes looks very untidy. Here's an example:
"Architectures are bounded context and not application specific. The architect for a simple bounded context with low complexity could be composed of a combination of a layered design with the transaction script pattern for the domain layer."
Architectures are bounded context? What does that mean? Or did he want to say that architectures are specific to bounded context but not to application? His words order looks like a programming code not like a human language (well, professional deformation perhaps, I understand). And then in the next sentence: "The architect for ... could be composed..." Did he want to say 'the architecture'? I know, this looks like a stupid typo. But such a language in two sentences one after another... And there are more of such examples.
December 27, 2017
What is DDD?
Domain Driven Design or DDD is an approach to software development that enables teams to effectively manage the constructions and maintenance of software for complex problem domains.
DDD has two kind of patterns:
1- Strategic patters that shapes the solution and it can be useful for any application.
2- Tactical pattern that are used to implement a rich domain model. They are only useful if your model is sufficiently rich in domain logic.
About the book
This is a perfect book for developers who are new to domain-driven design and want to learn what it's all about. But also developers who are more experienced when it comes to domain-driven design can benefit a great deal by reading this book. Not only does it have plenty of theory, it has plenty of practical examples in both diagrams and code.
A big plus is that the author reflected on many of the modern tendencies in application architecture such as CQRS, Event Sourcing, REST, Microservices, Messaging system etc.
Cons
There are plenty of references to .NET, it may not be a Pro for everyone.
Domain Driven Design or DDD is an approach to software development that enables teams to effectively manage the constructions and maintenance of software for complex problem domains.
DDD has two kind of patterns:
1- Strategic patters that shapes the solution and it can be useful for any application.
2- Tactical pattern that are used to implement a rich domain model. They are only useful if your model is sufficiently rich in domain logic.
About the book
This is a perfect book for developers who are new to domain-driven design and want to learn what it's all about. But also developers who are more experienced when it comes to domain-driven design can benefit a great deal by reading this book. Not only does it have plenty of theory, it has plenty of practical examples in both diagrams and code.
A big plus is that the author reflected on many of the modern tendencies in application architecture such as CQRS, Event Sourcing, REST, Microservices, Messaging system etc.
Cons
There are plenty of references to .NET, it may not be a Pro for everyone.
November 24, 2018
I first got myself introduced with the ddd concept by reading Martin Fowler’s blog. I then read the book of Eric Evans, read lot of articles in the web regarding the implementation of CQRS, DDD. In my opinion, Eric Evans book may be the bible of the concepts of DDD but anyone who wants implement DDD in real life should read this book. This book describes the concepts so clearly i finished the large book within two weeks. This book also helps me understand the concept of event store, what things we need to consider implementing my own event store, temporal queries which I didn’t found completely in any other source. Apart from that, it compares several of the design patterns with pros and cons in implementing DDD are well described with examples. I highly recommend any person who want to move on to the traditional application development to DDD, CQRS to read this book.
May 19, 2022
Really good companion to Eric Evans's famous blue book, Domain-Driven Design: Tackling Complexity in the Heart of Software. It explains what DDD is and isn't in clear, simple prose. There are lots of code samples to show implementation of some of the concepts and patterns. That's a two-edged sword. Sometimes it makes things clearer, sometimes it's a bit overkill. Since the book was written in 2014, the examples occasionally use oudated frameworks and pakages, making it hard to follow along.
June 17, 2022
An in-depth dive into the world of DDD, with an emphasis on the importance of collaboration with Domain Experts and many external references to the different knowledge crunching practices available out there.
While the book is not super-recent anymore, it was published 10 years after the blue book of Eric Evans and can therefore provide some insights about how the DDD community and practitioners have evolved, which I found quite interesting.
Be warned though, that it is a long book, and reading it can be sometimes overwhelming. But I think it is a needed step to really enter the world of DDD. Last advice: don't forget to practice!!
While the book is not super-recent anymore, it was published 10 years after the blue book of Eric Evans and can therefore provide some insights about how the DDD community and practitioners have evolved, which I found quite interesting.
Be warned though, that it is a long book, and reading it can be sometimes overwhelming. But I think it is a needed step to really enter the world of DDD. Last advice: don't forget to practice!!
February 4, 2018
Serves as an introduction to Architecting systems, Microservices, Domain Driven Design, and requirements gathering with customers.
Explores the strategic and tactical patterns that domain driven design covers such as Rest/RPC/SOAP, value objects, CQRS etc.
A great book if you're moving from an intermediate role to senior / architecting roles.
My only criticisms would be the sheer length, fairly dry writing, and it's choice of C# for coding samples (although that's just a personal nitpick).
Explores the strategic and tactical patterns that domain driven design covers such as Rest/RPC/SOAP, value objects, CQRS etc.
A great book if you're moving from an intermediate role to senior / architecting roles.
My only criticisms would be the sheer length, fairly dry writing, and it's choice of C# for coding samples (although that's just a personal nitpick).
December 14, 2024
This book is a useful companion to the Eric Evan's original "blue book" on Domain-Driven Design. Millet and Tune flip the order of Evan's book, discussing strategic patterns (bounded context, context maps) before the tactical ones (entities, aggregates, repositories ...). Particularly valuable are the additions of DDD-thinking emerged after the publication of the blue book, like events, event storming, and event sourcing.
The book is full of examples, all in C#, also relying on C# libraries. Nevertheless, the examples are also sufficiently accessible for developers using other languages.
The book is full of examples, all in C#, also relying on C# libraries. Nevertheless, the examples are also sufficiently accessible for developers using other languages.
June 30, 2020
So far my favourite book about the whole DDD topic. Although I don't have any experience in .NET it was quite easy for me to understand the idea and I learned about about the language as well.
Apart from that, the examples are clear and easy to understand and I really appreciate the structure of the chapters with the short explanations in theory, than code examples and a short summary at the end.
Apart from that, the examples are clear and easy to understand and I really appreciate the structure of the chapters with the short explanations in theory, than code examples and a short summary at the end.
March 20, 2018
The most up to date book about Domain Driven Design patterns I read so far. Every pattern is discussed from different angles and based on business scenarios. It covers different architectural patterns going from classic layered architecture to CQRS and Event Sourced systems. Many interesting patterns are discussed on how integrate different bounded context, etc. Really a god read.
April 30, 2021
It's probably one of the best books that I have read on DDD so far (mainly because it tries to be quite practical), but it's not a very good book in general. Maybe it's the too large number of concepts to cover, but many essential explanations are missing, and often the book focuses on wrong things in the examples. Still looking for a good book on DDD then.
June 10, 2020
Absolutely brilliant book about DDD. This one is the first full book I read about the topic and I learned a lot of it. It is not focused only in the technical aspect, it also gives relevance to the principles that will help you to build successful systems aligned with the business and users.
June 2, 2024
A fundamental book on Domain-driven design. I like it more than the book by Eric Evans as it focuses on what is the most important: strategical patterns and communication with domain experts. Comprehensive examples make this book a bit heavy, but it does not affect the value of this book
June 21, 2017
Covers many useful topics on DDD. Overall a bit dry and repetitive when explaining some concepts
July 21, 2018
I recommend this to anyone who is looking for practical knowledge of applying Domain-Driven Design in .NET applications.
October 17, 2018
I read this book for only event sourcing chapters, and I end up reading the entire book, Best book ever about domain driven design and specially event sourcing.
January 31, 2020
Very good well though out explanation on DDD. However you need some prerequisites to fully utilize this, IE, clean code and clean architecture.
April 22, 2020
Lots of updated concepts related to DDD: Domain Events, Event Sourcing, and a more detailed explanation of the collaboration with stakeholders
June 30, 2020
Without a doubt one of the best DDD books out there.
September 7, 2020
Niezła, można się sporo dowiedzieć, jak ktoś jeszcze nie wie za dużo o DDD. Ale kilka błędów, dużo razy powtarzane te same rzeczy – zwłaszcza na początku i trochę za dużo detali za świata .NET.
October 16, 2020
Probably my favourite DDD book, very good explanations
January 7, 2021
Many repetitions, the wrong definition of optimistic concurrency, didn't like the book.
June 26, 2021
Really detail explanation about DDD and software development approach.
Good for software developers and leaders and anyone who are in the software industry
Good for software developers and leaders and anyone who are in the software industry
Displaying 1 - 30 of 41 reviews