What do you think?
Rate this book
Learning Domain-Driven Design: Aligning Software Architecture and Business Strategy
Building software is harder than ever. As a developer, you not only have to chase ever-changing technological trends but also need to understand the business domains behind the software. This practical book provides you with a set of core patterns, principles, and practices for analyzing business domains, understanding business strategy, and, most importantly, aligning software design with its business needs. Author Vlad Khononov shows you how these practices lead to robust implementation of business logic and help to future-proof software design and architecture. You'll examine the relationship between domain-driven design (DDD) and other methodologies to ensure you make architectural decisions that meet business requirements. You'll also explore the real-life story of implementing DDD in a startup company. With this book, you'll learn how to:
340 pages, Paperback
Published November 16, 2021
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 30 of 63 reviews
January 23, 2023
No sense in talking about the solution before we agree on the problem.
Let's start with the elephant in the room: Eric Evans' classic book about domain-driven design (DDD). The book is so famous that it even has an affectionate nickname - "the blue book". It was published in 2004 and it established DDD as a topic. Totalling more than 500 pages, the blue book is extensive and it changed how many people thought about software development.
Vladik Khononov, author of Learning Domain-Domain Design, had quite a challenge in front of him. Whatever he wrote would be compared to the classic.
He surpassed the challenge. Learning Domain-Domain Design is practical, easy to read, and well structured. It doesn't go very deep on any of the ideas, but that's completely fine. It goes just deep enough. The content itself is up-to-date with modern software development practices.
If you're looking to learn about DDD, I recommend this book by Vladik Khononov. While Eric Evans' book will always have its place in software development history, Learning Domain-Domain Design has surpassed it as the the text to start with.
Let's start with the elephant in the room: Eric Evans' classic book about domain-driven design (DDD). The book is so famous that it even has an affectionate nickname - "the blue book". It was published in 2004 and it established DDD as a topic. Totalling more than 500 pages, the blue book is extensive and it changed how many people thought about software development.
Vladik Khononov, author of Learning Domain-Domain Design, had quite a challenge in front of him. Whatever he wrote would be compared to the classic.
He surpassed the challenge. Learning Domain-Domain Design is practical, easy to read, and well structured. It doesn't go very deep on any of the ideas, but that's completely fine. It goes just deep enough. The content itself is up-to-date with modern software development practices.
If you're looking to learn about DDD, I recommend this book by Vladik Khononov. While Eric Evans' book will always have its place in software development history, Learning Domain-Domain Design has surpassed it as the the text to start with.
July 31, 2022
I think this will be „THE“ DDD book of this decade.
The author explains the strategic and tactical patterns from the blue book based on practical experience and provides heuristics on which ones are recommended when.
He skillfully relates the patterns to modern techniques and patterns such as event sourcing or data mesh.
What also makes this book special is the ubiquitous consideration of the context map and how it changes over the lifecycle of the software as a whole and especially of the bounded contexts.
From this, further recommendations for strategic and tactical patterns are derived, making the book a valuable companion for practitioners.
The author explains the strategic and tactical patterns from the blue book based on practical experience and provides heuristics on which ones are recommended when.
He skillfully relates the patterns to modern techniques and patterns such as event sourcing or data mesh.
What also makes this book special is the ubiquitous consideration of the context map and how it changes over the lifecycle of the software as a whole and especially of the bounded contexts.
From this, further recommendations for strategic and tactical patterns are derived, making the book a valuable companion for practitioners.
July 30, 2022
A DDD (and in general, software engineering) gem.
First of all, for all of the newcomers to DDD - this is THE BOOK to read. Not Evans, not Vernon but this.
It manages to be both approachable and in-depth at the same time. Vladik managed to keep this engaging on strategic level while also being practical yet pragmatic on tactical level.
I'd say that audience for this is not only beginners, but the general DDD community.
As a DDD practicioner and long-term software engineer and architect, I'd say this book perfectly summarizes the domain driven landscape. It helps you organize all the pieces and practices together to be more efficient with solving the actual problem.
It does not - obviously - dig deep into any of the techniques or topics (as some reviewers suggested), but my understanding is, that it was never the goal.
If you look for good follow ups (and drill downs), I agree with most of the recommendations from Vladik at the end of the book.
Well deserved 5/5 👏
First of all, for all of the newcomers to DDD - this is THE BOOK to read. Not Evans, not Vernon but this.
It manages to be both approachable and in-depth at the same time. Vladik managed to keep this engaging on strategic level while also being practical yet pragmatic on tactical level.
I'd say that audience for this is not only beginners, but the general DDD community.
As a DDD practicioner and long-term software engineer and architect, I'd say this book perfectly summarizes the domain driven landscape. It helps you organize all the pieces and practices together to be more efficient with solving the actual problem.
It does not - obviously - dig deep into any of the techniques or topics (as some reviewers suggested), but my understanding is, that it was never the goal.
If you look for good follow ups (and drill downs), I agree with most of the recommendations from Vladik at the end of the book.
Well deserved 5/5 👏
December 26, 2021
Vlad Khononov's "Learning Domain-Driven Design" clearly explains how DDD helps design software solutions aligned to business strategy in 300 pages, a rare find in the DDD literature.
I particularly appreciated that Vlad is so well-connected to our industry, as demonstrated in Part IV, which discusses DDD's relationship with microservices, event-driven architecture, and data mesh.
Now that I have read it cover-to-cover, I can easily say it was one the best software-related books out of the 20 or so that I have read in 2021.
If you appreciate authors that create tight storylines with proper information density, then Vlad Khononov should be on your reading list.
I particularly appreciated that Vlad is so well-connected to our industry, as demonstrated in Part IV, which discusses DDD's relationship with microservices, event-driven architecture, and data mesh.
Now that I have read it cover-to-cover, I can easily say it was one the best software-related books out of the 20 or so that I have read in 2021.
If you appreciate authors that create tight storylines with proper information density, then Vlad Khononov should be on your reading list.
December 6, 2021
This is one of the best books for getting into Domain-driven design. Provides a modern perspective on the subject, it is easy to read, with clearly articulated ideas focusing mostly on the strategic part. Highly recommended.
March 1, 2023
Insightful. I particularly liked the part about data at the end..
January 24, 2023
just when you thought there’s nothing else to be said about Domain Driven Design after reading Evans and Vernon, Learning Domain Driven Design manages to cast a fresh light on it.
January 8, 2023
Last autumn, I caught Vlad Khononov at the GSAS conference in Barcelona.
Back then, I had zero knowledge of DDD. I was aware of a few popular architecture patterns, and that’s it. As a Full Stack web developer, my day-to-day job was glueing existing services and frameworks together rather than drawing sophisticated UML diagrams. Yet I was intrigued by conspiracy around software architecture topics. Take a look at this famous definition for example:
When I read Clean Architecture several years ago, I didn’t quite understand the book’s core ideas behind all that SOLID jargon, primarily because I couldn’t map the proposed “clean” solutions to my day-to-day experiences. Three years later, I finally started building that understanding, thanks to the “Learning Domain-Driven Design” book.
The book not only explains the DDD approach but also applies it to popular design and implementation patterns.
For example, I finally understood what Hexagonal architecture is and when to use it. On top of that, I’ve got an excellent overview of analytical data platforms. My favourite part of the book is Chapter 14: Microservices. I won’t attempt to summarise it here. Instead, I encourage you to read the book yourself if you are interested in a practical intro to the most common software architecture patterns such as Microservices, Event Driven Architecture, CQRS and more.
As a Full Stack developer, I found this overview very handy. I may not need all described patterns immediately, but I need to know they exist.
I must warn a fellow reader that a quick flip-through will not be enough if you are relatively new to software architecture. I had to take notes and re-read certain parts of the book to understand certain concepts.
If you are an individual contributor without enough power to install DDD on a company level, the book outlines some baby steps you can take to shift the whole company towards DDD.
The book wraps up nicely with a case study of applying DDD in real life. The author shares some of the mistakes he has made while learning DDD and how his understanding of DDD was evolving throughout the years.
To summarise, I'm very happy that I got a chance to read “Learning Domain-Driven Design”, and I recommend it to Backend and Full Stack developers as well as aspiring software architects.
The way Vlad writes is inspiring!
Back then, I had zero knowledge of DDD. I was aware of a few popular architecture patterns, and that’s it. As a Full Stack web developer, my day-to-day job was glueing existing services and frameworks together rather than drawing sophisticated UML diagrams. Yet I was intrigued by conspiracy around software architecture topics. Take a look at this famous definition for example:
“Architecture is about the important stuff. Whatever that is.” (Ralph Johnson)
When I read Clean Architecture several years ago, I didn’t quite understand the book’s core ideas behind all that SOLID jargon, primarily because I couldn’t map the proposed “clean” solutions to my day-to-day experiences. Three years later, I finally started building that understanding, thanks to the “Learning Domain-Driven Design” book.
The book not only explains the DDD approach but also applies it to popular design and implementation patterns.
For example, I finally understood what Hexagonal architecture is and when to use it. On top of that, I’ve got an excellent overview of analytical data platforms. My favourite part of the book is Chapter 14: Microservices. I won’t attempt to summarise it here. Instead, I encourage you to read the book yourself if you are interested in a practical intro to the most common software architecture patterns such as Microservices, Event Driven Architecture, CQRS and more.
As a Full Stack developer, I found this overview very handy. I may not need all described patterns immediately, but I need to know they exist.
I must warn a fellow reader that a quick flip-through will not be enough if you are relatively new to software architecture. I had to take notes and re-read certain parts of the book to understand certain concepts.
If you are an individual contributor without enough power to install DDD on a company level, the book outlines some baby steps you can take to shift the whole company towards DDD.
The book wraps up nicely with a case study of applying DDD in real life. The author shares some of the mistakes he has made while learning DDD and how his understanding of DDD was evolving throughout the years.
To summarise, I'm very happy that I got a chance to read “Learning Domain-Driven Design”, and I recommend it to Backend and Full Stack developers as well as aspiring software architects.
The way Vlad writes is inspiring!
February 27, 2023
Quando conheci este livro, eu sinceramente pensei: "Precisamos de MAIS UM livro de DDD?". Mas olhando os reviews e o sumário, resolvi dar uma chance (até porque eu também queria dar uma recapitulada no assunto).
No final das contas, gostei do livro. O grande mérito do autor é que ele conseguiu abordar o assunto de forma bem clara e objetiva.
Além disso, o livro traz assuntos que, embora não sejam novos, não haviam sido tratados nos livros "clássicos" de DDD. Por exemplo: a importância de utilizar diferentes designs, alinhados com a complexidade do subdomínio (ie, nem todo subdomínio exige um domain model e todos aqueles patterns táticos) e como DDD se relaciona com outros temas, como microservices, event-driven architecture e análise de dados.
Algumas pessoas podem achar o conteúdo mais raso que os antecessores, mas acredito que era o propósito mesmo não se aprofundar tanto em todos os temas. O enfoque do livro é estratégico, como explícito em seu título.
O único problema que vi neste sentido foi o autor não ter dedicado ao menos 1 capítulo para lidar com "persistência", pois é algo que eu acredito deixar muitas dúvidas para os menos experientes com aggregates.
Enfim, recomendo a leitura, mas vale retornar aos livros clássicos (o livro azul do Evans e o vermelho do Vernon) para se aprofundar nos tópicos que deixarem mais dúvidas. Em termos de implementação, o livro do Vernon é o mais indicado.
No final das contas, gostei do livro. O grande mérito do autor é que ele conseguiu abordar o assunto de forma bem clara e objetiva.
Além disso, o livro traz assuntos que, embora não sejam novos, não haviam sido tratados nos livros "clássicos" de DDD. Por exemplo: a importância de utilizar diferentes designs, alinhados com a complexidade do subdomínio (ie, nem todo subdomínio exige um domain model e todos aqueles patterns táticos) e como DDD se relaciona com outros temas, como microservices, event-driven architecture e análise de dados.
Algumas pessoas podem achar o conteúdo mais raso que os antecessores, mas acredito que era o propósito mesmo não se aprofundar tanto em todos os temas. O enfoque do livro é estratégico, como explícito em seu título.
O único problema que vi neste sentido foi o autor não ter dedicado ao menos 1 capítulo para lidar com "persistência", pois é algo que eu acredito deixar muitas dúvidas para os menos experientes com aggregates.
Enfim, recomendo a leitura, mas vale retornar aos livros clássicos (o livro azul do Evans e o vermelho do Vernon) para se aprofundar nos tópicos que deixarem mais dúvidas. Em termos de implementação, o livro do Vernon é o mais indicado.
December 28, 2022
This is a very good book which brings a lot of clarity to DDD concepts. It shows how to use those concepts giving a lot of examples, describes tradeoffs between architectural approaches and their usage.
January 25, 2022
A good introduction to DDD , but for me it's not that practical and deep .
April 15, 2022
Pretty much the best programming book I’ve read. It had the perfect ballance between modern enterprise practice and theory.
Loved it from start to finish and even though i am a big fan of functional programming i think this can be applied everywhere
The author also responded to some of my questions pn Twitter so obviously 5 starts for the tech support
Loved it from start to finish and even though i am a big fan of functional programming i think this can be applied everywhere
The author also responded to some of my questions pn Twitter so obviously 5 starts for the tech support
December 22, 2022
This is the ultimate and best book on DDD.
Just read it, do yourself a favor.
Just read it, do yourself a favor.
February 11, 2023
Okay, it took me a while to finish this book, not because the book had gone into details, but because I'm a messy reader. This book gives you just enough info to make you curious and go read elsewhere if you want more on the subject. I wish I had read this instead of reading the whole "Data mesh" book earlier. Some topics are a bit repeating if you have read other DDD books, but i think it's a great starter or summarizer around it.
Well done.
Well done.
September 1, 2021
A quick overview, easy to understand some terminologies about DDD, suitable for new beginner, the one have no idea what is DDD.
December 6, 2022
Not as techncial as I would have expected.
There were a couple chapters on figuring out how to match a technical design with the business aspects. I learned that creating a ubiqutious language between the technical and business domain is very important, and we should initially put a lot of care towards this, as it will save many hours of confustion for new developers when context is not as fresh.
There were a couple chapters on figuring out how to match a technical design with the business aspects. I learned that creating a ubiqutious language between the technical and business domain is very important, and we should initially put a lot of care towards this, as it will save many hours of confustion for new developers when context is not as fresh.
October 29, 2021
A really good stuff, full of non-trivial observations and advices. Even if you, like me, are too busy to read every book from cover to cover, spend some time on skimming trough chapters lettng your eyes to stop you on most intriguing places (it worked for me at least). Readng O'Realy online on desktop was ok, but on my Android tablet all source code snippets were misformatted.
It's a trully great contribution to preserving/restoring the software industry sanity (chapters on combining DDD with other techniques are must read IMHO with this specific regard). Clarifications about interplay between Bounded Contexts and Sub-Domains is another important topic to pay a close attention to. Vald's resolution of this misterious and arcane topic might seem over-simplictis, but it's extremelly pragmatic and useful.
editremove
It's a trully great contribution to preserving/restoring the software industry sanity (chapters on combining DDD with other techniques are must read IMHO with this specific regard). Clarifications about interplay between Bounded Contexts and Sub-Domains is another important topic to pay a close attention to. Vald's resolution of this misterious and arcane topic might seem over-simplictis, but it's extremelly pragmatic and useful.
editremove
November 22, 2022
A great read!
October 9, 2022
"Learning Domain-Driven Design" neatly covers a particular integration between business strategy and software architecture, addressing both strategic and tactical issues in architecture, programming, testing, organizational structure, business strategy, and even data infrastructure. It is a very effective summary of how Domain-Driven Design (DDD) is applied today.
Is it the perfect introduction to DDD? It would be for many, but it certainly wouldn't be for me. For me, it has left out many subjects I considered most compelling in the original introduction to DDD. Some of the key topics not included are:
* how gathering domain knowledge actually works: how to interact those outside of software about what their domain really consists of
* domain-layers, or how different aspects of the domain function with different logics of interaction and characteristic rates of change, even outside of the context of software as such
* similarly, there was no coverage of abstract cores, which this the delegation to the simplified domains of physics, math, or logic that provide key computational steps, and thus is one of the key signatures of core subdomains in creating value.
Indeed, what we have here is "all manager, no engine"; creating a setting for events to happen and be carried along gracefully and coherently, but not how to turn the core ideas of the domains being considered into the subdomains that constitute the core value of the business.
Yet, even in this emptiness, there is value; everything surrounding the most core value has been simplified and given workable heuristics. It's a valuable simplification for any business. What remains unmentioned is only the complexity at the core of software.
Is it the perfect introduction to DDD? It would be for many, but it certainly wouldn't be for me. For me, it has left out many subjects I considered most compelling in the original introduction to DDD. Some of the key topics not included are:
* how gathering domain knowledge actually works: how to interact those outside of software about what their domain really consists of
* domain-layers, or how different aspects of the domain function with different logics of interaction and characteristic rates of change, even outside of the context of software as such
* similarly, there was no coverage of abstract cores, which this the delegation to the simplified domains of physics, math, or logic that provide key computational steps, and thus is one of the key signatures of core subdomains in creating value.
Indeed, what we have here is "all manager, no engine"; creating a setting for events to happen and be carried along gracefully and coherently, but not how to turn the core ideas of the domains being considered into the subdomains that constitute the core value of the business.
Yet, even in this emptiness, there is value; everything surrounding the most core value has been simplified and given workable heuristics. It's a valuable simplification for any business. What remains unmentioned is only the complexity at the core of software.
May 12, 2022
This one is a book that I happily suggest to everyone who wants to dive into domain-driven design and also into a bit of architecture. It includes the complete run-down of all the essential parts and also describes methods to reach this point, like event storming.
All code examples are written in C#, but I thin they are easy enough to understand for programmers - specially ones well versed in Java.
All code examples are written in C#, but I thin they are easy enough to understand for programmers - specially ones well versed in Java.
November 6, 2022
Intimidated by the famously long and difficult "blue book". Highly recommended this much easier to digest DDD book. Has nice clear explanations of event sourcing, CQRS, and Datamesh to boot
October 6, 2022
Great book! Strategic and tactical design patterns are explained excellently. In addition to DDD there is also nice explanations of event storming, microservices, event-driven architecture and other modern architectural concepts and patterns (Layered Architecture, Ports & Adapters, CQRS, ...)
October 21, 2023
I might be a bit biased as I’ve already read Evan’s an Vernon’s books so the subject of DDD is not new for me.
This book is better written and much easier to read than previous ones, but for someone like me it’s not worth it as this doesn’t bring any new information.
This book is better written and much easier to read than previous ones, but for someone like me it’s not worth it as this doesn’t bring any new information.
June 20, 2022
One of the best books ever written about strategic part of DDD.
March 6, 2023
I cannot say that I was impatiently looking forward to read this book. I couldn't find any reasonable argument for another position about DDD. However, since domain modelling is "my world" and I've seen many positive reviews, I had decided to read it. Do I regret it? Absolutely not! I've found a lot of fresh and useful knowledge in there.
What I liked:
- The biggest argument against DDD has always been introducing an unnecessary complexity aka accidental complexity. Raw and context-less applying tactical patterns eventually leads to the large and unmaintainable project. Many DDD knowledge sources put a lot of effort to thoroughly explain all those patterns - value objects, repository, policies etc. How much of above you can find in "Learning Domain-Driven Design"? One chapter! (15-20 pages). The emphasis on identifying types of your subdomains first is admirable. The alternatives for domain model (transaction script, active record, out-of-house solutions) are widely spread across the entire book. Ultimately, if you had had an impression that domain model pattern is a good fit for most of your projects, after this book you'll definitely change your mind.
- Many chapters about DDD-related topics. EDA vs DDD, microservices vs DDD , data reporting vs DDD (this is one is extremely fresh).
- Much effort put into explaining components integration area. I appreciate pragmatic tips and a lot of accentuating an importance of encapsulation and not exposing your internals (private events vs public events; published language - OHS; ACL). I also enjoyed the part about bounded context boundaries (start with bigger and decompose instead of having fancy but impractical micro-service per aggregate).
- Simple language and easy to grasp heuritics and diagrams.
What I didn't like:
- Well, actually only one thing. As I mentioned previously, this is another book about DDD. There is plenty of them in the market already. I think I've read most of them and unfortunately I couldn't avoid moments of feeling that some parts are simply redundant.
How to conclude it? I would say that this is a brilliant book but the content has been widely covered by other positions. However, I would still recommend it as a first step for someone who wants to dive into DDD ocean :)
What I liked:
- The biggest argument against DDD has always been introducing an unnecessary complexity aka accidental complexity. Raw and context-less applying tactical patterns eventually leads to the large and unmaintainable project. Many DDD knowledge sources put a lot of effort to thoroughly explain all those patterns - value objects, repository, policies etc. How much of above you can find in "Learning Domain-Driven Design"? One chapter! (15-20 pages). The emphasis on identifying types of your subdomains first is admirable. The alternatives for domain model (transaction script, active record, out-of-house solutions) are widely spread across the entire book. Ultimately, if you had had an impression that domain model pattern is a good fit for most of your projects, after this book you'll definitely change your mind.
- Many chapters about DDD-related topics. EDA vs DDD, microservices vs DDD , data reporting vs DDD (this is one is extremely fresh).
- Much effort put into explaining components integration area. I appreciate pragmatic tips and a lot of accentuating an importance of encapsulation and not exposing your internals (private events vs public events; published language - OHS; ACL). I also enjoyed the part about bounded context boundaries (start with bigger and decompose instead of having fancy but impractical micro-service per aggregate).
- Simple language and easy to grasp heuritics and diagrams.
What I didn't like:
- Well, actually only one thing. As I mentioned previously, this is another book about DDD. There is plenty of them in the market already. I think I've read most of them and unfortunately I couldn't avoid moments of feeling that some parts are simply redundant.
How to conclude it? I would say that this is a brilliant book but the content has been widely covered by other positions. However, I would still recommend it as a first step for someone who wants to dive into DDD ocean :)
March 21, 2024
The book is well written and with its style it makes is easy to understand. But the concept around the software part of Domain Driven Design is a different matter. I simply dislike it. If you are reading this, bear in mind my context my be different than yours, and perhaps you will gain from the book, which was definitly a pleasant read.
I consider boundaries and seams in any business as a possible approach towards "splitting up" a piece of software. But in reality my experience says that, psycical boundaries does a lot more towards this, since I believe the organization and the psycology in it is the real showstopper of how software is implemented.
The more people around building a piece of software the harder everything becomes. Splitting up by business seams and business boundaries/contexts, is the first step towards a more granular approach towards explicit boundaries.
We should strive towards that, of course. Whenever you have a clearer organizational unit - a small team - the reason for all the explicit DDD patterns becomes less important because you have already psyhically aligned towards a certain boundary and context, and not multiple. That makes things a lot easier.
How you then implement the code, on your side of the fence, should not matter to anyone on the outside of your domain. But if you really believe the DDD patterns are an approach towards clearer architecture I would urge you to first look at whether your domain is truly to large for a single team to cope with.
I also to some extent believe any success with a microservices approach stems somewhat from what DDD has has to offer. I definitly respect that and believe the patterns around understanding boundaries and contexts - which today should be implemented within smaller teams and small explicit responsibilty - is using what DDD set out to teach.
Well written. Great subject. Too convoluted for me and to large design priniciples for most people to cope with.
I consider boundaries and seams in any business as a possible approach towards "splitting up" a piece of software. But in reality my experience says that, psycical boundaries does a lot more towards this, since I believe the organization and the psycology in it is the real showstopper of how software is implemented.
The more people around building a piece of software the harder everything becomes. Splitting up by business seams and business boundaries/contexts, is the first step towards a more granular approach towards explicit boundaries.
We should strive towards that, of course. Whenever you have a clearer organizational unit - a small team - the reason for all the explicit DDD patterns becomes less important because you have already psyhically aligned towards a certain boundary and context, and not multiple. That makes things a lot easier.
How you then implement the code, on your side of the fence, should not matter to anyone on the outside of your domain. But if you really believe the DDD patterns are an approach towards clearer architecture I would urge you to first look at whether your domain is truly to large for a single team to cope with.
I also to some extent believe any success with a microservices approach stems somewhat from what DDD has has to offer. I definitly respect that and believe the patterns around understanding boundaries and contexts - which today should be implemented within smaller teams and small explicit responsibilty - is using what DDD set out to teach.
Well written. Great subject. Too convoluted for me and to large design priniciples for most people to cope with.
March 12, 2023
For all of the newcomers to DDD - this is THE BOOK to read.
This practical book provides you with a set of core patterns, principles, and practices for analyzing business domains, understanding business strategy, and most importantly, aligning software design with its business needs. Author tells the story of DDD in a unique way providing a great perspective for learning. Book content structure is excellent and you can learn every aspect of DDD.
Examining different communication patterns and providing excellent guidance for selecting architectural patterns for implementing DDD are the best part of the book.
Author provides information through diagrams, tables and charts and they are so useful and help you learn complex concept very easily and help you make decision about different aspect of you software architecture.
One thing that differentiate this book from others is that pay attention to business and how we as software architecture or software developer must aligning software design with business needs. Author gives some good recommendations about how we can do it.
This practical book provides you with a set of core patterns, principles, and practices for analyzing business domains, understanding business strategy, and most importantly, aligning software design with its business needs. Author tells the story of DDD in a unique way providing a great perspective for learning. Book content structure is excellent and you can learn every aspect of DDD.
Examining different communication patterns and providing excellent guidance for selecting architectural patterns for implementing DDD are the best part of the book.
Author provides information through diagrams, tables and charts and they are so useful and help you learn complex concept very easily and help you make decision about different aspect of you software architecture.
One thing that differentiate this book from others is that pay attention to business and how we as software architecture or software developer must aligning software design with business needs. Author gives some good recommendations about how we can do it.
July 9, 2023
This book has to be the most accessible and clear introduction available for those interested in learning and applying the principles of Domain Driven Design (DDD). I would highly recommend that readers pick up this book over often the classic Eric Evans text (Domain-Driven Design: Tackling Complexity in the Heart of Software) or the also popular Implementing Domain-Driven Design book.
While the book is good and includes some useful appendixes at the back - such as a case study on applying DDD. I still question how easy it will be for a reader to apply the book's learning to their own workplace. While Vladik Khononov identifies a number of ways to gradually introduce the practice into your workplace, he also states that DDD may need to be pitched to stakeholders.
In my personal experience DDD differs so dramatically from the standard development practices used widely in the industry - that the actual act of stakeholder and developer buy in is one of the most problematic parts of applying DDD.
While the book is good and includes some useful appendixes at the back - such as a case study on applying DDD. I still question how easy it will be for a reader to apply the book's learning to their own workplace. While Vladik Khononov identifies a number of ways to gradually introduce the practice into your workplace, he also states that DDD may need to be pitched to stakeholders.
In my personal experience DDD differs so dramatically from the standard development practices used widely in the industry - that the actual act of stakeholder and developer buy in is one of the most problematic parts of applying DDD.
May 1, 2024
The book covers key concepts in DDD:
- Strategic Patterns: Ubiquitous language, Bounded Contexts, Sub-domain
- Tactical Patterns: Entities, Value Objects, Aggregates, Domain Services, Domain Events
- Implement patterns: layer architecture, ports and adapters architecture, CQRS
This book also discusses about relationship between DDD and microservices, event-driven and data mesh architecture.
I haven't read Evans's book before. This could be a good book to start on DDD.
Some notes:
- Starts with big bounded contexts and extends to smaller bounded contexts later when we have more knowledge on business domain.
- There are 2 complexities: complexity of implementation and complexity of communication. Extracting too many smaller microservices will increase the complexity of communication, which results in a distributed big ball of mud.
- Strategic Patterns: Ubiquitous language, Bounded Contexts, Sub-domain
- Tactical Patterns: Entities, Value Objects, Aggregates, Domain Services, Domain Events
- Implement patterns: layer architecture, ports and adapters architecture, CQRS
This book also discusses about relationship between DDD and microservices, event-driven and data mesh architecture.
I haven't read Evans's book before. This could be a good book to start on DDD.
Some notes:
- Starts with big bounded contexts and extends to smaller bounded contexts later when we have more knowledge on business domain.
- There are 2 complexities: complexity of implementation and complexity of communication. Extracting too many smaller microservices will increase the complexity of communication, which results in a distributed big ball of mud.
December 20, 2023
This is a book on applying DDD in practice. Overall, I like this book, but it has some extra unneeded info, in my opinion.
Overall, the author does a great job explaining what DDD is and what isn't. Sharing what arch patterns and approaches on how to simplify things. He does really great job on domains and subdomains, mapping those into bounded contexts.
In the second part of the book, you can find more practical info and real-life scenarios.
What I didn't like - some chapters that either had very rare usage or seemed to be unrelated to DDD (like data mesh). I would love to see more examples of how to demystify DDD and different approaches in more detail. But this is minor.
This is a great book to finish book challenge for this year.
Overall, the author does a great job explaining what DDD is and what isn't. Sharing what arch patterns and approaches on how to simplify things. He does really great job on domains and subdomains, mapping those into bounded contexts.
In the second part of the book, you can find more practical info and real-life scenarios.
What I didn't like - some chapters that either had very rare usage or seemed to be unrelated to DDD (like data mesh). I would love to see more examples of how to demystify DDD and different approaches in more detail. But this is minor.
This is a great book to finish book challenge for this year.
Displaying 1 - 30 of 63 reviews