Implementing Domain-Driven Design

by Vaughn Vernon

Implementing Domain-Driven Design presents a top-down approach to understanding domain-driven design (DDD) in a way that fluently connects strategic patterns to fundamental tactical programming tools. Vaughn Vernon couples guided approaches to implementation with modern architectures, highlighting the importance and value of focusing on the business domain while balancing technical considerations.

Building on Eric Evans’ seminal book, Domain-Driven Design, the author presents practical DDD techniques through examples from familiar domains. Each principle is backed up by realistic Java examples–all applicable to C# developers–and all content is tied together by a single case study: the delivery of a large-scale Scrum-based SaaS system for a multitenant environment.

The author takes you far beyond “DDD-lite” approaches that embrace DDD solely as a technical toolset, and shows you how to fully leverage DDD’s “strategic design patterns” using Bounded Context, Context Maps, and the Ubiquitous Language. Using these techniques and examples, you can reduce time to market and improve quality, as you build software that is more flexible, more scalable, and more tightly aligned to business goals.

Genres: Programming, Technology, Software, Computer Science, Technical, Architecture, Nonfiction

656 pages, Hardcover

First published January 1, 2013

Reviews

[Alessandro · Rating 1 out of 5]

The amount of frustration I felt reading this book is directly proportional to the value I see in domain-driven design.

As others have noted you'll have to read a lot for little information. I totally agree and here are a couple of examples I have at hand:
[p. 402 - Repositories - Introduction]
"there are circumstances under which a collection-oriented design will work for you, and circumstances when it is best to use a presistence-oriented design. I first discuss when to use and how to create a collection-oriented Repository and follow that with a treatment of persistence-oriented ones.";
[same page, two paragraph below under the title Collection-Oriented Repositories]
"it's possible that it won't work for you. If your persistence mechanism prevents you or hampers your ability to design with a collection perspective, see the following subsection. I address the conditions under which I think collection-oriented design works best. To do so I need to estalish some fundational background."

Other times I found the almost exact same text presented twice on the same page:
[p. 302 - in the highlighted section titled "Be Careful about What the Event handler Does"]
"Remember, the Application Service controls the transaction. Don't use the Event notification to modify a second Aggregate instance. That breaks a rule of thumb to modify one Aggregate instance per transaction."
[and immediately after]
"One thing the subscriber should not do is get another Aggregate instance and execute modifying command behavior on it. This would violate the modify-single-aggregate-instance-in-single-transaction rule of thumb, as discussed in Aggregates."

I found it really upsetting. Especially as I had to filter through all this zero-value chatter, to learn something about the topic. This is not the only case where information was obscured under heaps of words. My guess is that the book could have been at least 2/3 of its size if the author had wrote it in a concise form. Considering it's a book for professionals I find it unacceptable.

There is also another aspect I disliked about the writing style, which is the use of double negation, and more in general a wrong-example-first presentation style.
An example of a sentence using double negation is at p. 64: "Of course, there is no rule that says that more meaning cannot be added to these names. That's a decision of your team".
How does that feel compared to this: of course, your team might want to add more meaning to these names.

Regarding the "wrong-example-first" style, what I mean is that the DDD principles are often (if not always) introduced with a bad-design example first. Followed by chatter and then the good-example. While I think it is useful to compare good and bad designs, I found it tiring to read the description of a bad-example while waiting for so much anticipated concepts of DDD to be presented. I thought I was supposed to keep the bad-example in mind in order to relate it with what was about to follow. I thought that would give me a better understanding. But in the end I found it more tiring than useful.
In retrospective I can definitely say that's not the way I like to learn. Imagining I wanted to learn how to play tennis I'd prefer to be shown how to move properly before being warned about pitfalls and typical errors. Likewise I would have preferred to be presented a clear, as simple as possible, concept to be memorized and then used as an anchor to understand the dangers I could face departing from it.
I'm not sure what the average learning style of the target reader is, perhaps for someone else reading what-not-to-do first works better.

I've been also deluded by the examples inspired by "real-life", as found the stories about this hypothetical team entering the world of DDD just a boring self-affirming narrative in third-person of what the team did wrong initially and how happy they where when they finally embraced the tenets of DDD. I was hoping to read some typical QA dialogs bewteen developers and business domain experts. I was hoping to be presented typical cues to look for in a dialog indicating an DDD pattern might be appropriate.
Perhaps that's expecting too much, yet I did not gain much insight reading the story of the SaasOvation team and this contributes to my bad impression about the book.

To conclude, I think the intention behind this this book is good. I appreciated the emphasis on the importance of strategic design versus simplistic adoption of tactical patterns. I guess the author loves and knows how to properly apply DDD principles in real life, and I think he should consider to rewrite it.

To the reader looking for an introduction to DDD, I'd say: look elsewhere.
I've found a few reviews about Evan's seminal book saying it's very verbose as well, and new concepts emerged after its publication are not covered, so perhaps not that one either.

== UPDATE 7 Jun 2015 ==
While writing this review I noticed another book titled "Patterns, Principles and Practices of Domain-Driven Design". I'm not affiliated with the author or anything related with that book. I was so frustrated with "Implementing, Domain-Driven Design" I thought I had better find something else to read.
The two books have a very similar table of contents. So I picked a topic and compared how it was presented before buying it. Well, you know I decided to buy it after that test and so far I've been loving 95% of the pages.
The book style is what I look for: consistent and concise language, general to detail presentation style, right-first-wrong-after examples, (really) meaningful concepts highlighted, simple diagrams to aid visualizing the conceptual landscape.
I'm not writing any excerpt here as it would be premature, and I'll finish reading it before drawing the conclusion, but if I'll be happy as I am now when I finish it I'll give it 4+ stars without the shadow of a doubt.
It's big (700+ pages) but it's well structured and I think easy for the reader to find only the relevant parts. The size is also justified by plenty of pictures (diagrams and UI screenshots) and code presented in the second half. The examples are written in C#, I'm a Java developer. I had no issue understanding what they mean. Actually I preferred them as C# is more concise, so less to read to get what I need.

I hope this will help the community as there are so many projects turning in a "big-ball-of-mud"!

[Piotr · Rating 2 out of 5]

It was a really painful book to read. I had some rough idea what DDD is about beforehand and most of the time I was bored. There were some new inspiring insights, some useful structured explanation how things should be done, but most of the contents were rather dull. I hope there is a better introductory book for DDD, as I cannot recommend this one.

Whenever there was a text explaining an example code, I usually read about 10% of it, because 90% of it talked about things that were obvious by looking at the code. I also did not like the writing style, so most of the time I was skimming through the book rather than reading it. The ‘Cowboy Logic’ jokes might be funny for Americans, but they only managed to irritate me from time to time. Every chapter had to open with a smart-sounding quote from a famous person, usually not having even a distant connection to software making (Napoleon in Domain Events!) - sorry, such cheesy tricks won’t buy me. What was worse, sometimes the author invented his own sayings, like this one: “If our models were music, they would have the unmistakable sound of completeness, purity, power, and possibly even elegance and beauty.” (page 69).

I had a problem trusting the author as the sample code contained many code smells or dubious practices. I understand it needs to be simplified and short in order to fit into a long book, but keeping the code simple does not not justify some cases I encountered. The author has a strange approach to immutable classes - maybe because the book is a bit dated. He does not use final/readonly fields, and in the same time suggests a copy constructor is necessary to test ‘if the class is immutable’ - like it wasn’t simpler and safer to create an another instance using the same parameters (page 244). There is a null assigned to a list field (page 298), a HashSet used to perform operations only available in HashMap (page 405) and a constructor only calling super() (page 473). An if statement nested 3 times can be seen on page 461 - you don’t have to be a clean code expert to suggest using an early return instead.

Too many bad parts to skip in order to reach the parts worth learning.

[Sebastian Gebski · Rating 4 out of 5]

It's good, but it was supposed to be better.
First, it doesn't repeat the basics from the Blue Book - that's a pro.
Second, it extends the DDD content by some ideas that appeared in DDD lingo after Blue Book appeared (like Domain Events) - that's a pro as well.
Third, it contains a very, VERY good appendix about event sourcing - that's a big pro.

But the majority of content is ... a bit unconvincing, you can't feel much of the value added. Examples are said to mimick RL, but they don't seem really challenging, quite the opposite (and the code formatting in Kindle version is AWFUL).

Would I recommend this book:
a.) To someone who hasn't read the Blue Book? Hellnoes, go get the Blue Book now!
b.) To someone who has read the Blue Book? Well, if BB left you puzzled and confused, go for it. Otherwise, you can grab it for Event Sourcing appendix, but in general it won't rock your world.

One, more final remark: will this book teach you how to make good models if you're fresh'n'green in design stuff? Not likely, as the challenges and situations described in the book have to be encountered in RL first, so you get a basic idea, what the fuss is about (IMHO).

[Hynek · Rating 1 out of 5]

I hate to do this but this book is absolutely unreadable and I’ve given up after 300 pages.

It’s often touted as the more approachable alternative to “The Big Blue Book” by Eric Evans, but it’s not an alternative, it’s a companion!

Instead of properly defining things, it constantly refers to the Evans book. It manages to be too hand-wavy (can’t follow arguments about decisions) and too low-level at the same time (spends interminable time on Java and Hibernate idiosyncrasies).

My original reason to pick it up was to solidify my my overall understanding of DDD after learning about it mostly from fragmented sources, but turns out that conference talks on YouTube are better than this and I say it as someone who absolutely hates video content.

[Rob · Rating 4 out of 5]

Short version: excellent book on the DDD philosophy, and both the strategic and tactical patterns that you can use to apply that philosophy to your software projects. Be forewarned though, this all comes with a cost, and requires significant discipline. For best results, read as part of a group or book club.

A few additional details:

1. If you're in a hurry, read Domain-Driven Design DistilledDomain-Driven Design Distilled. Given that IDDD is over 600 pages, it is... comprehensive. If you just need to do a survey to get down some of the basics, "test drive" it with DDDD.

2. Read as part of a book club. It's comprehensive and dense. Certain concepts and practices appear straightforward, while others are sophisticated. While it's possible to derive some (even significant) value from the text while reading on your own, it's a good idea to get some friends/colleagues to join in and talk through some of the stickier bits.

3. Pace yourself; don't try to do it all. As the title suggests, this book is about putting these philosophies and patterns into practice for real-world software projects. Read carefully though, and think through what's being presented. Not everything in here is "silver bullet" material; that said, everything comes with some kind of cost -- whether it's additional cognitive overhead, bracing yourself for much refactoring, or spending some political capital w/in your organization to put all this into practice.

[Eugenio · Rating 5 out of 5]

Высоко-концентрированный опыт лидеров отрасли. Обильной воды, о которой некоторые пишут не заметил. Зато заметил невероятное количество ответов на вопросы человека, овладевшего ��еорией DDD, но не понимающего как её применить. Книга имеет огромную практическую ценность. От разъяснения неоднозначных абстрактных понятий до разобранных примеров реализации. Золото!

[Miloš · Rating 5 out of 5]

DDD Masterworks: the Red Book - check!

Let me first start with a list of the book's failings.

First off, I can't see anyone taking in everything that this book has to offer without first going through the Blue Book (colloquial name for Eric Evans's seminal DDD book) and let's be honest - that one can be a tough nut to crack and people can get stuck reading it (guilty as charged, had to return to it and start from the beginning half a year later).

Secondly, I wish the author took his own advice on defining what constitutes a Bounded Context and applied it to his writing - in a lot of chapters, especially the first ones, there's an overflow of words, a piling of whole paragraphs that don't do enough (or much) to clarify the concepts and the matter at hand. They're waffle whose purpose is either to reiterate what has already been said, to illustrate something that needs no further illustration or to (in later chapters) make you feel like you were a part of SaasOvation's decision-making/brainstorming meetings. Granted, the last one was interesting and easy to read but still felt like a bit of a waste of both paper and time.

Finally, some parts of the book haven't aged well - there's a lot of attention being given to ORM in general and Hibernate in particular but that's understandable seeing the original publication date.

That being said, I've enjoyed the book quite a bit and found it much easier to take in than its blue predecessor and I'm not ashamed to admit that there were several ohhh and aha moments concerning concepts that felt a bit vague and abstract in EE's DDD work.

Choosing collaboration and project management domains for the examples and telling the tale of a software team practicing DDD at a company working in those domains was a bullseye - one of the drawbacks of the Blue Book was that sometimes the domains of the examplew were too foreign to me to follow the DDD-talk effortlessly so I first had to put in an effort to understand the business sense and then see how DDD made implementing that easier.

Here, the domain was easy to follow since most of us software folks use similar tools on a daily basis or have used them before so there's no learning curve/cognitive tax to pay in order to see what the examples were designed to make us see. And making the examples easy to see and follow meant that the point was also easier to get across and sell (not that it needed much selling).

All in all, a pretty useful, practical and even a tad bit enlightening read and one that I will definitely be returning to in days to come.

[Tomasz Bartczak · Rating 1 out of 5]

It's quite slow and steady, and some Java examples are really not presenting what they should, e.g. Publish-Subscribe implementation with crazy ThreadLocal in there... https://books.google.pl/books?id=X7Dp...

[Ieva Gr · Rating 5 out of 5]

Follows “real life” team navigating from bad to good design decisions
Provides considerations of benefits and drawbacks for most decisions taken (which I think is awesome for exercising your own critical thinking – trying to see with how many of these you could come up yourself)
Provides implementation examples with code snippets and explanations
Additional information about things like Architecture styles, RESTful’ness and etc.

[Muhammad Sufyian · Rating 5 out of 5]

The book has enough details on tactical aspects of DDD, however it covers strtaegic aspects of DDD at very high level.

[Benjamin · Rating 3 out of 5]

I don't remember ever struggling more to get through a book than when reading this one. I kept feeling like the requirements to properly understand the book included "having read this book already" – kind of difficult.

Much of this came down to the author's decision to start with the strategic patterns before covering the tactical ones. He gives a reason for doing so, which I can't remember, but I do remember that he references the tactical patterns an awful lot before actually covering them. I don't see what would be lost if, e.g., value objects and entities were covered a lot earlier.

And then, even within a chapter, I had to look extremely hard to find clean definitions of the main things being discussed. When definitions did show up, more often than not they were quotes from Evans' Domain-Driven Design: Tackling Complexity in the Heart of Software, leaving me wondering if I wouldn't have been better off reading that one instead. One reason for not doing so was the fact that Evans' original DDD book is more than a decade older, but maybe I should still read it anyway.

A few more minor quibbles:

- There is a strong focus on Java and Hibernate; if you happen to not work with either, the examples sometimes aren't very instructive.

- The "Implementing" in the title is sometimes taken too literally; I definitely started glossing over the 101st implementation example of roughly the same thing

- "Cowboy Humor". I can only imagine the discussions between editor and author about them. "If those aren't in the book, I'll walk!" - "But Vaughn, they're neither funny nor instructive!" - "I'll walk!"

- Some chapters keep referencing code examples at http://lokad.github.com/lokad-iddd-sa..., which is neither what the link for a GitHub page nor a GitHub repo looks like; it just forwards to a 404 page, and looking at https://github.com/Lokad doesn't show any "IDDD" repos. I could only find https://github.com/jimitndiaye/lokad-....

This all being said, the main value from reading the book came from discussing it among colleagues, which often led to "aha" moments. Without that, I might have given up.

Since I now meet the requirements to understand the book (having read it already), I could go back and read it again, but it was just too painful. I'm considering reading Domain-Driven Design Distilled by the same author as a kind of extended summary, but not for a while. A long while.

[Rene Stein · Rating 4 out of 5]

Slušně napsaná kniha o Domain driven designu s několika zásadními nedostatky.

Tím hlavním je podle mě to, že bez podrobné znalosti Evansovy knihy bude čtenář při výkladu některých vzorů a postupů tápat, co se mu autor snaží naznačit.

1)První dvě kapitoly - motivace, proč se zajímat o DDD a výklad o "Bounded contextech", "Core domain", "Subdomain", Generic subdomain" "Supporting domain" apod. jsou snad ještě nudnější a rozvleklejší než kapitoly v kanonickém díle o DDD od Evanse (http://www.amazon.com/Domain-Driven-D...). Žák předčil mistra. Kdo zná knihu od Evanse, ocení, jak pracné muselo sesmolení takových užvaněných kapitol být. Další kapitoly jsou už mnohem lepší.

2) Slabinou knihy je i výklad aggregate roots (AR), kvůli kterému jsem si knihu kupoval, protože mě zajímalo, jak autor (AR) identifikuje. I když autor píše u AR o svých "rules of thumb", jeho pravidla jsou neurčitá, závislá na kontextu ("it depends", "it depends", Olalala) a navíc se podle mě dostává kvůli snaze nějak AR obhájit k tomu, že začíná likvidovat silné stránky DDD/objektového modelu - místo řiditelných asociací na objekty doporučuje do AR vkládat jen "Id" (hodnotovou identitu) asociovaných a agregovaných objektů. A to v jiné části říká, že by doménový model neměl být otrocky závislý na struktuře relační databáze (souhlas), ale poté hájí jen trochu maskované "cizí klíče" v rozhraní objektů. Utvrdil jsem se v tom, že mé modely jsou bez AR mnohem použitelnější a netrpí ničím z toho, co autor zmiňuje, když se s AR od počátku nepočítá jako s výsostnou konstrukcí v kódu, pomocí které se modelují a kódují přirozené - z mého pohledu nepřirozené a zcela arbitrérní - "hranice" mezi třídami v doméně.

3) Některé ukázky kódu přestavují spíš antivzory - konstruktory přecpané argumenty, podivné dělení odpovědností mezi třídami, pojetí infrastrukturní vrstvy při hexagonální architektuře. Ke konci knihy je tolik výpisů opakujícího se kódu, že mi kód přišel jen jako výplň vhodná pro rychlé generování nasmlouvaného počtu stránek, než že by pro výklad bylo takové množství kódu nutné a pomáhali čtenáři pochopit některé konstrukce ze světa DDD.

4) Nejcennější je asi výklad vzoru-přístupu "Event sourcing", který v Evansově knize není. Také je dobré, že autor nejen zmínil CQRS, ale upozornil i na rizika, která neofyté ve světě CQRS blažeností často podceňují.

5)Někomu by mohlo vadit, že většina příkladů je psána v Javě, jen v příloze je použit C#.

Přesto - pro vážné zájemce o DDD knihu doporučuju. Je dobré porovnat své postupy s postupy a argumenty někoho, kdo se s DDD sžil a má odlišné názory.

[Dina Bogdan · Rating 5 out of 5]

I've read the book from a junior perspective that faced before some DDD principles and implementations. Also, I've read before the book several articles and viewed some talks about Domain Driven Design. The book helped me to understand what I've already faced before, to create a mindset of how I should develop a project from a DDD perspective, or how to improve your team velocity using DDD strategies and tactics.
The book is structured really well, has a lot of code examples that are pretty simple as syntax, but complicated at the same time as design. I personally feel that if you want to read this book you should have some prerequisites to understand over 70% of it. Certainly, when I will be in my senior years, I will read again this book.

[Oleksandr · Rating 2 out of 5]

Hard language, not very good examples. I started reading Evans book, I didn't understood why I even started reading this book.

[Ranil · Rating 3 out of 5]

It's a terrible read, don't get me wrong: what's being said is great it's just soooooo long and not fun to read. I'd recommend his "distilled" book and then dive into the specific subjects when needed with other resources (incl. this book)

[Guilherme Labrego · Rating 1 out of 5]

This book was so terrible and painful to read that I almost forgot to write a review and tell why I disliked this. I think that Alessandro’s review reflects exactly what I felt reading this “big ball of mud”.

https://www.goodreads.com/review/show...

[Tan Pham · Rating 4 out of 5]

First try on this book. For entry level like me, the book provides me many ideas to implement domain driven design. I totally ignore the cowboy part in each chapter, it doesn’t make me laugh at all. :)

[Shahriyar Nasir · Rating 5 out of 5]

An essential read for all software developers, Implementing Domain Driven Design provides practical guidance on how to understand and model the problem spaces encountered by software. Vaughn Vernon goes into depth in each chapter starting out with the Strategic DDD patterns and finishing up with the Tactical patterns. I especially liked the story that he laced throughout of a team that encountered domain modeling challenges. This team used DDD to overcome each challenge. IDDD is a dense book and I'd recommend reading the first half about the higher level strategic content like a story. The tactical content in the second half can be skimmed and then read just-in-time as one encounters the corresponding problems in their codebases. DDD is a platform agnostic approach to software development that will continue to outlast any trends or fads in software. The sooner you learn about DDD and start practicing software development linguistically, the quicker you'll be on your way to building high value applications.

One word of caution when reading IDDD is to glance past parts that aren't relevant. For example, I found that much of the book is written in Java and with a focus on Java enterprise architectural patterns (e.g. Hibernate), something that I don't do professionally.

[Michał Olejnik · Rating 3 out of 5]

Ok, so I have definitely mixed feelings about this book. I'm a big fan of the DDD itself and the original book by Eric Evans. I've heard a lot of good things about this book as well and my expectations were high. And I'm afraid they weren't quite met unfortunately. The part dedicated to strategic DDD is good. The concepts are explained thoroughly and understandably, the examples are easy on point and the whole part reads well enough and stood the test of time. But the part dedicated to tactical DDD didn't age well. In my opinion there's too much focus and references on outdated technologies that you need to power through and that only pollute the most important ideas and make it harder to grasp them. I also didn't quite enjoy the style the book is written in - especially the way each chapter concludes (rather than telling what the reader just learned it would be better to provide a short summary of the most important content in my opinion). And I unfortunately don't understand the cowboy logic/humour. In the end, I think there's still a lot of knowledge in this book (especially about strategic DDD). It can definitely give you some value but don't expect an easy read.

[Stan · Rating 4 out of 5]

If you are starting your journey in domain-driven design then this is one of the very few books you ought to pay attention to. Despite being somewhat long, the information contained within is easily attained. The style of writing can be a bit boring at times as the author likes to take his time explaining new & old concepts.

I recommend playing with DDD and its tactical patterns for a while before revisiting this book again. There are certain aspects of DDD that are hard to grok initially before you and your team have had a chance to exercise them in the wild.

The author has recently released his new book, Domain-Driven Design Distilled, which is a great continuation to Implementing Domain-Driven Design.

[Kaspars Laizans · Rating 2 out of 5]

Got it, because was recommended by a colleague, who did read Evan`s Blue Book (BB) and this. He said, that this is easier to read and better suited for getting into DDD. Haven't read BB yet, but IDDD seems a bit chaotic, as if it's meant to be a reference book. First chapters often refer to last chapters, which require some understanding of previous chapters. I would call it a dependency hell.
It does have some good points and examples, but generally wouldn't recommend as a book for a beginner. It's probably better to read some other materials first (BB, perhaps?) to get acquainted with basic ideas, terms and some architectural solutions. Only then it's worth to delve into the realm of actual implementations.

[Vinicius Souza · Rating 5 out of 5]

DDD is, in some contexts, a very conceptual topic. After reading the origin Evans's book you will probably end up with a lot of questions about how to implement some of the ideas of the book. This book answers most of these questions. It is a complement to the original book, with a more practical view and a lot of code samples. Speaking for architects and developers, I believe this book delivers more value than the Evans's, once it is much more close to our daily challenges.

In addition to DDD, the book addresses a lot of subjects ahead of its time, which are the base for microservices architectures and reactive systems.

Finally, I'd say that this book is a must for every senior developer and system architect.

[Lai Duy Ha · Rating 3 out of 5]

When you doubt about what you believed before about N-Layer. When you are struggling for determine the logic with big service layer, and dump (anemic) models with ORM & DTO then this book is for you.

As DDD - Tackling Complexity could be consider as theory textbook. Implementing DDD filling the gap between theory and practical.

It points out the pitfalls of our current architecture design (N-layers), and show how could we re-thinking about design approach with practical examples. You will find yourself when you're reading this book. I'm sure!!!

[Toby · Rating 4 out of 5]

Verbose and the “cowboy logic” parts didn’t make any sense but that aside, a comprehensive walkthrough of good software design techniques and principles in the DDD world, though some are universal. Some content feels dated, particularly specific references to Hibernate for example, and the major focus on OOO. Quality of chapters varies. I found the book to be a good companion to the blue book because it explains concepts more concretely. Like anything, these ideas have to be used purposefully in real life, rather than as a grab bag of patterns to apply.

[Selim · Rating 5 out of 5]

It greatly explains most of things that you may not get in the first time while reading Blue Book. Chapters are organized well and well explained by real world examples and trade-offs. For me, Blue Book was mostly theory but this book is the practice. Now many of the things are clear for me because after reading Blue Book I had a lot of questions in mind. Really recommended for people who are interested to learn more about DDD.

[Miguel Alho · Rating 5 out of 5]

very interessting book and approach to The associated tópics. not a straightfoward read (had to constantlty go back to reread certain parts as i went along) but well worth it. probably should reread it sometime in The future (2 years from now, maybe) to consolidate The ideais.

[Jeff Dalton · Rating 5 out of 5]

Very good book that provides pragmatic advice for implementing DDD concepts into your organization. Vaughn provides several very solid pieces of code that can jump start your base libraries for Domain Events, Aggregate Base, Value Object Base, and Repository Base.

[Dmitry · Rating 5 out of 5]

Vernon gives thorough treatment to the DDD topic, covering lots of ambiguity in concepts that I had in mind after finishing Evans’s DDD. Highly recommended. Also, make sure to check out sample code on github.

[Michał Niczyporuk · Rating 5 out of 5]

This book is way better then Evans' 'blue book' . Its written in plain English, using simple examples.
Chapter by chapter we're introduced into new elements of DDD, and author explains all neuances very well.

[Antonio · Rating 5 out of 5]

Very good technical book, if you are interested in Domain Driven Design this is your go to for questions. It's like the Bible but for DDD very big but worth every page. The examples are very clear and it's explained from the basics.