What do you think?
Rate this book
Domain-Driven Design Distilled
Domain-Driven Design (DDD) software modeling delivers powerful results in practice, not just in theory, which is why developers worldwide are rapidly moving to adopt it. Now, for the first time, there’s an accessible guide to the basics of What it is, what problems it solves, how it works, and how to quickly gain value from it. Concise, readable, and actionable, Domain-Driven Design Distilled never buries you in detail–it focuses on what you need to know to get results. Vaughn Vernon, author of the best-selling Implementing Domain-Driven Design, draws on his twenty years of experience applying DDD principles to real-world situations. He is uniquely well-qualified to demystify its complexities, illuminate its subtleties, and help you solve the problems you might encounter. Vernon guides you through each core DDD technique for building better software. You’ll learn how to segregate domain models using the powerful Bounded Contexts pattern, to develop a Ubiquitous Language within an explicitly bounded context, and to help domain experts and developers work together to create that language. Vernon shows how to use Subdomains to handle legacy systems and to integrate multiple Bounded Contexts to define both team relationships and technical mechanisms. Domain-Driven Design Distilled brings DDD to life. Whether you’re a developer, architect, analyst, consultant, or customer, Vernon helps you truly understand it so you can benefit from its remarkable power. Coverage includes
176 pages, Paperback
Published May 23, 2016
335 people are currently reading
1769 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 152 reviews
February 6, 2017
I have not read other DDD books, so I grabbed this one as a quick intro to decide if I wanted to dive deeper. My conclusion: either DDD is a useless pile of nonsense, or this book, much like homeopathy, has distilled the original material to such an extent that there is nothing left of value.
The book provides no context around DDD. What motivated the creation of DDD? What problems does DDD solve? Who should use it? At what stage of a project should you use it? What are the alternatives? What are the drawbacks? Instead of answering these questions, the book just claims "DDD is great!", talks about how the author of this book is also the author of another best-selling book on DDD, and then jumps into defining a bunch of DDD terms (e.g. Bounded Contexts, Ubiquitous Language, Domain, Context Map, Aggregate, Value Object, and Event Storming). The definitions for these terms are, to put it kindly, vague and circular. Here's a typical example:
"A Bounded Context is a semantic contextual boundary. This means that within the boundary each component of the software model has a specific meaning and does specific things. The components inside a Bounded Context are context specific and semantically motivated."
A bounded context is a contextual boundary? Your software components do specific things? No way!
What makes this worse is that there are no real-world examples or case studies. Most of that content is the same kind of high-level drivel as above (note: every one of the DDD terms is italicized every single time its used), and the rare low-level detail often feels utterly irrelevant, such as what color sticky notes you must buy (apparently, light orange, purple, and green are a must for Event Storming). The only somewhat concrete example in the book is how to use DDD to model all the buzzwords of Scrum (sprint, retrospective, backlog, etc), but such an example is confusing on multiple levels. First, it's not clear why you would use DDD to model a methodology as opposed to a concrete piece of software. Second, to understand scrum, you have to introduce all sorts of new buzzwords, which distracts you from whatever DDD buzzword you're actually trying to understand. And third, the book recommends using DDD as part of scrum, so then you get a confusing overlap between the process you are using to model things and the actual thing you are modeling.
Occasionally, an interesting or nuanced detail would come up, and the author would immediately tell you to go look at another book to learn more. In fact, I think the real goal of this book is not to teach you anything useful, but to get you interested enough to buy the author's other books. Obviously, not every book can cover every topic, so recommending other books is a perfectly reasonably thing to do, so long as you provide *some* value of your own. This book, does not.
So, here is the distilled version of this book:
Draw bubble charts of your architecture. Group related bubbles together. Congratulations, you may now join the ranks of UML-obsessed whiteboard architects.
The book provides no context around DDD. What motivated the creation of DDD? What problems does DDD solve? Who should use it? At what stage of a project should you use it? What are the alternatives? What are the drawbacks? Instead of answering these questions, the book just claims "DDD is great!", talks about how the author of this book is also the author of another best-selling book on DDD, and then jumps into defining a bunch of DDD terms (e.g. Bounded Contexts, Ubiquitous Language, Domain, Context Map, Aggregate, Value Object, and Event Storming). The definitions for these terms are, to put it kindly, vague and circular. Here's a typical example:
"A Bounded Context is a semantic contextual boundary. This means that within the boundary each component of the software model has a specific meaning and does specific things. The components inside a Bounded Context are context specific and semantically motivated."
A bounded context is a contextual boundary? Your software components do specific things? No way!
What makes this worse is that there are no real-world examples or case studies. Most of that content is the same kind of high-level drivel as above (note: every one of the DDD terms is italicized every single time its used), and the rare low-level detail often feels utterly irrelevant, such as what color sticky notes you must buy (apparently, light orange, purple, and green are a must for Event Storming). The only somewhat concrete example in the book is how to use DDD to model all the buzzwords of Scrum (sprint, retrospective, backlog, etc), but such an example is confusing on multiple levels. First, it's not clear why you would use DDD to model a methodology as opposed to a concrete piece of software. Second, to understand scrum, you have to introduce all sorts of new buzzwords, which distracts you from whatever DDD buzzword you're actually trying to understand. And third, the book recommends using DDD as part of scrum, so then you get a confusing overlap between the process you are using to model things and the actual thing you are modeling.
Occasionally, an interesting or nuanced detail would come up, and the author would immediately tell you to go look at another book to learn more. In fact, I think the real goal of this book is not to teach you anything useful, but to get you interested enough to buy the author's other books. Obviously, not every book can cover every topic, so recommending other books is a perfectly reasonably thing to do, so long as you provide *some* value of your own. This book, does not.
So, here is the distilled version of this book:
Draw bubble charts of your architecture. Group related bubbles together. Congratulations, you may now join the ranks of UML-obsessed whiteboard architects.
July 17, 2016
I kind of always had this hunch that Domain-Driven Design was something of a buzzword fad, that it likely described something I was already doing regularly and that the book and the approach likely just lent formality and terminology to common sense activities. After all, the biggest thing I see referenced seems to be this Ubiquitous Language stuff, which I think just means using the same nouns for stuff as the domain experts, which I try to do anyway so I'm sure I'm already doing everything in the book, right? Nope. I was flat wrong, which is why I consider this book a must-read for engineers who do a lot of greenfield work, domain modeling, and architecture.
Early on, the author provides a sort of toy example that will stay with us for the duration of the book, designing the domain for a Scrum management product. I've actually worked a job where I did this very thing, so this resonated fairly strongly. The book suggests that, if engineers are left to their own devices, they'll design around code generality to reduce duplication, so there might be like a ScrumElement that could be a Product or a BacklogItem, and there's like a generic ScrumElementContainer which could be either a Sprint or Release. I'm just reading this section like, yeah, that's exactly what I would do... in fact I did that. Is that bad? But the rest of the book explains exactly why that's bad, and exactly how to do it better. Chapter after chapter, the book showed me the ways in which my approach to domain modeling was disastrously bad and how much better it could be. It also explained how, with this alternative approach, my domain would lend itself more easily to modular system design along service-oriented boundaries.
In short, this book is excellent and completely changed how I think about and model domain objects at work. The book can sometimes be light on detail, I often found myself wanting more information, or stronger examples of exactly how something should work, but at the end of the day that's the purpose of this book - a short introduction that encourages the reader to dive in deeper with Domain Driven Design or Implementing Domain Driven Design. As such, I can't really complain about the general lightness of this book, as it's the primary reason it was such an easily digestible 197 pages.
Overall, this book is a must-read, I wish it existed years ago. I think back to all the times that a group of coworkers and I would gather in front of a whiteboard and model domain objects together without a single domain expert in the room. It makes me slap my head at how idiotic my approach has been for over a decade, the ways that I let database and technical concerns dictate the design of domain objects rather than the business's needs. I can never look at this regularly-performed process the same way, which is why it joins my list of Career-Changing Books.
Early on, the author provides a sort of toy example that will stay with us for the duration of the book, designing the domain for a Scrum management product. I've actually worked a job where I did this very thing, so this resonated fairly strongly. The book suggests that, if engineers are left to their own devices, they'll design around code generality to reduce duplication, so there might be like a ScrumElement that could be a Product or a BacklogItem, and there's like a generic ScrumElementContainer which could be either a Sprint or Release. I'm just reading this section like, yeah, that's exactly what I would do... in fact I did that. Is that bad? But the rest of the book explains exactly why that's bad, and exactly how to do it better. Chapter after chapter, the book showed me the ways in which my approach to domain modeling was disastrously bad and how much better it could be. It also explained how, with this alternative approach, my domain would lend itself more easily to modular system design along service-oriented boundaries.
In short, this book is excellent and completely changed how I think about and model domain objects at work. The book can sometimes be light on detail, I often found myself wanting more information, or stronger examples of exactly how something should work, but at the end of the day that's the purpose of this book - a short introduction that encourages the reader to dive in deeper with Domain Driven Design or Implementing Domain Driven Design. As such, I can't really complain about the general lightness of this book, as it's the primary reason it was such an easily digestible 197 pages.
Overall, this book is a must-read, I wish it existed years ago. I think back to all the times that a group of coworkers and I would gather in front of a whiteboard and model domain objects together without a single domain expert in the room. It makes me slap my head at how idiotic my approach has been for over a decade, the ways that I let database and technical concerns dictate the design of domain objects rather than the business's needs. I can never look at this regularly-performed process the same way, which is why it joins my list of Career-Changing Books.
February 19, 2017
Vernon is a longtime practitioner of DDD and as such, this book won't tell you any lies. However...
The book fails to accurately distill DDD to its core: iterative exploration of domain models together with business. Too much focus is put on the modelling artefacts. This book tries to reduce DDD to the mandatory use of a few of the most-known patterns in a very hierarchical way, claiming that this is enough to solve any problem in a DDD style.
Not only that, but the book also fails to distinguish details from core by not giving enough context to the reader. With this book alone, the reader will not be able to know what is essential and what can be experimented with. Nor could they hope to learn from applying DDD in practice.
I'm also not convinced that this is a good book to give to management, or sales, or any of the other intended audiences. It is too easy to conclude from this book that DDD is a linear process, where we eventstorm a model, 1-on-1 translate that in software (Vernon even includes a way of estimating how long that will take) and as such have a working product. I cannot believe this approach will work out for any non-trivial project. Software design is an inherently complex business, and no amount of best practices will make it possible to take away all the risks.
This book might be valuable to read in a team where at least a few team members have a strong foundation of what DDD is all about. Do not use this book to get started with DDD without any other guidance.
The book fails to accurately distill DDD to its core: iterative exploration of domain models together with business. Too much focus is put on the modelling artefacts. This book tries to reduce DDD to the mandatory use of a few of the most-known patterns in a very hierarchical way, claiming that this is enough to solve any problem in a DDD style.
Not only that, but the book also fails to distinguish details from core by not giving enough context to the reader. With this book alone, the reader will not be able to know what is essential and what can be experimented with. Nor could they hope to learn from applying DDD in practice.
I'm also not convinced that this is a good book to give to management, or sales, or any of the other intended audiences. It is too easy to conclude from this book that DDD is a linear process, where we eventstorm a model, 1-on-1 translate that in software (Vernon even includes a way of estimating how long that will take) and as such have a working product. I cannot believe this approach will work out for any non-trivial project. Software design is an inherently complex business, and no amount of best practices will make it possible to take away all the risks.
This book might be valuable to read in a team where at least a few team members have a strong foundation of what DDD is all about. Do not use this book to get started with DDD without any other guidance.
July 29, 2021
A very compact and richly informative book that summarizes the DDD principles in action in a very short amount of time; this helps get up to speed if the project needs quick actions.
You might even want to further dig into the topic with Vaughn Vernon's another book: Implementing Domain-Driven Desgin ; this book is vast and very detailed and you might need it if you want to deep dive in the DDD architecture.
You might even want to further dig into the topic with Vaughn Vernon's another book: Implementing Domain-Driven Desgin ; this book is vast and very detailed and you might need it if you want to deep dive in the DDD architecture.
October 29, 2017
I have already read Domain-Driven Design from Eric Evans and Implementing Domain-Driven Design from Vaughn Vernon and I think it is a good alternative to review the subject without reading tons of pages from the two books cited before. Besides that, this book better explains some topics when compared to its predecessors and focus on the most important parts from an architecture perspective. But I do not recommend this book as an introduction to the subject.
August 23, 2016
This is the very first book I read about DDD, and I have enjoyed it.
Examples were very clear and reading it was very easy.
Maybe a little bit "superficial", but I guess being a "distilled" edition, you can not ask for more.
The only thing that I didn't like at all is having a continuous and periodic reminder (more than 30 times!!) from the author that we could find much more detail in his "Implementing Domain-Driven Design" book.
It was quite annoying, to be honest: once at the very beginning and once and the end, would have been enough.
Besides that, I highly recommended if you want to start learning about "that DDD stuff" :-)
Examples were very clear and reading it was very easy.
Maybe a little bit "superficial", but I guess being a "distilled" edition, you can not ask for more.
The only thing that I didn't like at all is having a continuous and periodic reminder (more than 30 times!!) from the author that we could find much more detail in his "Implementing Domain-Driven Design" book.
It was quite annoying, to be honest: once at the very beginning and once and the end, would have been enough.
Besides that, I highly recommended if you want to start learning about "that DDD stuff" :-)
October 11, 2016
Great start, hungry for a deeper dive
Read
June 13, 2016I think I've read all the 'key' books about DDD (blue, red, PPP of DDD), so my goal wasn't to learn anything from this book. I wanted to fix another problem - sadly, surprisingly many people have trouble with going through blue book: it's not a trivial read, especially for someone inexperienced, who haven't encountered actual problems with complex domain modelling. So I've wanted to check whether this booklet could be a sufficient substitute for such a person - is such a primer good enough to get someone completely green DDDing?
The answer is ... I guess so.
Fortunately VV didn't just shorten EE's text. He tried to truly grasp the essence of DDD (on both - tactical & strategic level) & present it the reader in a practical way (e.g. he described Event Storming) w/o overwhelming him with terms like repositories, factories, etc. If you've read & comprehended blue / red book, you don't have anything new / interesting here, otherwise it may not be such a bad idea to start your familiarity with DDD by reading this book.
The answer is ... I guess so.
Fortunately VV didn't just shorten EE's text. He tried to truly grasp the essence of DDD (on both - tactical & strategic level) & present it the reader in a practical way (e.g. he described Event Storming) w/o overwhelming him with terms like repositories, factories, etc. If you've read & comprehended blue / red book, you don't have anything new / interesting here, otherwise it may not be such a bad idea to start your familiarity with DDD by reading this book.
May 25, 2017
After breezing through this thin booklet, I can only come to two possible conclusions:
1) DDD cannot be distilled, or
2) DDD is about communication, and not about lot's of vague concepts and terms people love to read about in technical books.
The most important part is completely missing - why use DDD (or why not). Furthermore, if you manage to find something that peaks your interest, Vaughn simply refers to his fatter "implementing DDD" book and continues on to the next topic, pretending there wasn't anything there in the first place.
I am convinced that DDD isn't something special or new or complex or mystic or holy. It's simply stating in your code what your business is about and keeping things separate. That's it.
1) DDD cannot be distilled, or
2) DDD is about communication, and not about lot's of vague concepts and terms people love to read about in technical books.
The most important part is completely missing - why use DDD (or why not). Furthermore, if you manage to find something that peaks your interest, Vaughn simply refers to his fatter "implementing DDD" book and continues on to the next topic, pretending there wasn't anything there in the first place.
I am convinced that DDD isn't something special or new or complex or mystic or holy. It's simply stating in your code what your business is about and keeping things separate. That's it.
January 18, 2022
Really good book. After reading DDD Distilled, now I can jump into a more advance book to learn the implementation part of DDD. Vaughn did a good job on keeping it short and sweet but still delivering the content that keep the reader to know more.
I could also recommend this book for management as they could gain knowledge that would help them to enhance relationship with their development team.
I could also recommend this book for management as they could gain knowledge that would help them to enhance relationship with their development team.
August 31, 2018
If you never heard about Bounded Contexts, Ubiquitous Language, Strategic Design, Subdomains, Context Mapping, Aggregates and Domain Events, then this book that will explain all the basics you need to know and get you up to speed and into the DDD world.
April 18, 2020
The book purports to give a distilled overview of DDD yet spends entire pages adding useless fluff around concepts. The material presented could have been better compressed into 5-10 slides or a blog post, instead of 120-odd pages. Lastly, the author concludes with this stupidity, losing any remaining credibility, not only coming off as elitist, but killing any motivation for a reader to even attempt good, sensible software design.
"One of the most important means to successfully employing DDD on a project is to hire good people. There is simply no replacement for good people, and above-average developers for that matter. DDD is an advanced philosophy and technique for developing software, and it calls for above-average developers, even very good developers, to put it to use."
"One of the most important means to successfully employing DDD on a project is to hire good people. There is simply no replacement for good people, and above-average developers for that matter. DDD is an advanced philosophy and technique for developing software, and it calls for above-average developers, even very good developers, to put it to use."
February 22, 2022
I’ve enjoyed this book very much. As a software engineer I have to consume a lot of content to stay up to date. In addition to that, getting back to a book when you are touching a subject at work can be hard to find exactly what you need.
DDD Distilled exactly helped me with this. To the point, distilled content, without the noise. Will this book teach you DDD thoroughly, will it make you eat and breath DDD? No - but that’s not the idea of a “distilled” book.
I would love to see more books in this format, it would serve me well in becoming a better engineer.
Easy to read, to the point, perfect for reminding you of some concepts and tips. This copy isn’t far of my desk.
DDD Distilled exactly helped me with this. To the point, distilled content, without the noise. Will this book teach you DDD thoroughly, will it make you eat and breath DDD? No - but that’s not the idea of a “distilled” book.
I would love to see more books in this format, it would serve me well in becoming a better engineer.
Easy to read, to the point, perfect for reminding you of some concepts and tips. This copy isn’t far of my desk.
August 4, 2016
For me 4.5, but I'll give it 5. Great, fast read, interesting intruducion to DDD. When you want to start with DDD or encourage your college, it's the best start point. I've read Implementing Domain-Driven Design already, so it was quite good reminder. There are lots of references from DDDD to IDDD. For me the best chapter in DDDD was about Event Storming, I've heard this buzzwords, but now I know what this technique is.
May 20, 2019
The best quick read on DDD that I have personally found.
July 24, 2019
As an introduction to DDD this a good starting point. It offers basic understand of DDD goals and presents some tools to create better software. Now it is time to grab the next book in the series.
August 24, 2021
This is a must-read for anyone serious about their career and evolvable software and high-quality systems.
January 11, 2022
Great book to refresh knowledge about DDD. liked it even more than a “blue book”.
February 18, 2022
Good overview of DDD, very fast to read. I can recommend it as good book to introduce you to the DDD field. Definitely not enough to practice it.
April 8, 2020
Oh well - this book is a bit weird.
It is hard to grasp, why the author is so convicted in regard to DDD, it almost feels like a religion to me. I normally don't have problems with people who believe in something, but when every third sentence contains something like all will be well once you've read this book and/or use this technique, it is a bit tiring. And it sometimes feels like a kind of brochure, when every paragraph contains ad to another book.
I think the book is a good starter to the whole DDD topic, but requires further reads.
It is hard to grasp, why the author is so convicted in regard to DDD, it almost feels like a religion to me. I normally don't have problems with people who believe in something, but when every third sentence contains something like all will be well once you've read this book and/or use this technique, it is a bit tiring. And it sometimes feels like a kind of brochure, when every paragraph contains ad to another book.
I think the book is a good starter to the whole DDD topic, but requires further reads.
January 15, 2017
A welcome, easy to read introduction to DDD which quickly touches on all the major concepts and provides some decent examples of applying the main patterns. The last chapter in particular, focused on strategies for implementation, is welcome. Some topics (aggregates comes to mind) are tackled a bit _too_ quickly for my liking, but I guess that's a prompt to go read the longer version.
March 4, 2017
A good, quick overview of DDD that still takes the time to contextualize things with a lot of examples and visuals. I already knew a fair bit about DDD through discussions and some guidelines at work, but this was useful to go through myself and understand things better.
December 6, 2020
A short and concise book to introduce Domain Driven Design (DDD) core knowledge and how to implement it. It is not meant to be a comprehensive guide to DDD. I enjoyed reading it to refresh my understanding of DDD, especially since it has been a while since I last read Eric Evan's DDD book.
August 16, 2016
Highly recommended read for anyone new to DDD or as a concise refresher.
November 1, 2018
Great way to Kickstart your DDD journey. easy to read and lays down foundation for further DDD study
June 7, 2016
this is a great book to get started on DDD or quickly review concepts associated. it makes for a great onboarding text for juniors coming in to a team that uses DDD, or a review for other levels to make sure a shared technical vocabulary is in use. it also presents good detail into some comunication techniques like Event storming that will work for anyone who hasn't tried it out yet.
highly recomended as a starting point, especially before going into deeper, heavier texts (from this author and others). deeper insight will come from other texts.
highly recomended as a starting point, especially before going into deeper, heavier texts (from this author and others). deeper insight will come from other texts.
March 25, 2022
The Distilled version is much easier digestable than the wordy Implementing DDD version. It breaks into 2.5 parts: Strategic design - the meaning of Domain Story telling and finding bounded contexts; Tactical design and design patterns; and finally Approaches to DDD - from Event Storming, Agile Development, SWOT Analysis, Modeling debt and estimating effort. The third part seems a bit smaller, but all the relevant basics are contained.
I like the book as a compact summary and reference. I would recommend it together with E.Evans DDD - tackling complexity at the heart of Software.
I like the book as a compact summary and reference. I would recommend it together with E.Evans DDD - tackling complexity at the heart of Software.
November 3, 2020
It's a shame that I cannot get the two hours of my life I spent reading this book back. The author bandies about terms with definitions that are so nonspecific they lose any meaning to the reader. I am either unconvinced by DDD or this book did not appropriately explain it.
January 15, 2022
This is a great distillation of DDD if you need a refresher or a high level view. Recommended for engineering and product execs looking for a quick skill up.
September 30, 2022
Fine for what it was. I learned a few things and it wasn’t too boring. Some parts felt a little too theoretical and hard to actually implement in the real world.
Displaying 1 - 30 of 152 reviews