What do you think?
Rate this book
Domain-Driven Design: Tackling Complexity in the Heart of Software
Domain-Driven Design fills that need. This is not a book about specific technologies. It offers readers a systematic approach to domain-driven design, presenting an extensive set of design best practices, experience-based techniques, and fundamental principles that facilitate the development of software projects facing complex domains. Intertwining design and development practice, this book incorporates numerous examples based on actual projects to illustrate the application of domain-driven design to real-world software development.
Readers learn how to use a domain model to make a complex development effort more focused and dynamic. A core of best practices and standard patterns provides a common language for the development team. A shift in emphasis–refactoring not just the code but the model underlying the code–in combination with the frequent iterations of Agile development leads to deeper insight into domains and enhanced communication between domain expert and programmer. Domain-Driven Design then builds on this foundation, and addresses modeling and design for complex systems and larger organizations.Specific topics covered
With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.
Readers learn how to use a domain model to make a complex development effort more focused and dynamic. A core of best practices and standard patterns provides a common language for the development team. A shift in emphasis–refactoring not just the code but the model underlying the code–in combination with the frequent iterations of Agile development leads to deeper insight into domains and enhanced communication between domain expert and programmer. Domain-Driven Design then builds on this foundation, and addresses modeling and design for complex systems and larger organizations.Specific topics covered
With this book in hand, object-oriented developers, system analysts, and designers will have the guidance they need to organize and focus their work, create rich and useful domain models, and leverage those models into quality, long-lasting software implementations.
563 pages, Kindle Edition
First published August 20, 2003
2204 people are currently reading
16524 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 326 reviews
April 19, 2015
This book is impossible to rate.
The ideas in this book are incredibly useful, and I am grateful to the author for sharing them with the software development community. In this perspective, not reading this book borders on professional negligence.
Unfortunately, I find the writing practically impenetrable. There are so many quaint and opaque verbs and adjectives that never get defined or even justified. Does "tightening" make a model "richer" and/or "deeper"? What about "enriching"? Is either one distinct from "distilling"? Is a "sharp" design always "supple" and vice versa? Could you "sharpen" a model too, or does it only apply to designs? What is it about the nature of domains that makes "carve off" a suitable description of what you do when you separate out a subdomain? What does it mean for knowledge to be "crunched"? There are so many vague terms, so many implied metaphors! Why? I am convinced that it would be possible to present these terrific ideas in a much more -ah- "distilled" form. With a "tighter" vocabulary. As it is, I am using a high-concentrate mixture of willpower and espressos to force my way through because I need the insights buried underneath the text.
The book also suffers from poor editing. There is quite a bit of redundancy, and some discussions lack focus. Many of the introductions or summaries to chapters could have been cut in their entirety. I've even found the same sentence repeated just a few paragraphs apart - something that just a single alert proofreader capable of focusing throughout the text should have caught. But it *is* hard to keep that focus.
It is a crying shame, since the underlying ideas and intentions are so good.
The ideas in this book are incredibly useful, and I am grateful to the author for sharing them with the software development community. In this perspective, not reading this book borders on professional negligence.
Unfortunately, I find the writing practically impenetrable. There are so many quaint and opaque verbs and adjectives that never get defined or even justified. Does "tightening" make a model "richer" and/or "deeper"? What about "enriching"? Is either one distinct from "distilling"? Is a "sharp" design always "supple" and vice versa? Could you "sharpen" a model too, or does it only apply to designs? What is it about the nature of domains that makes "carve off" a suitable description of what you do when you separate out a subdomain? What does it mean for knowledge to be "crunched"? There are so many vague terms, so many implied metaphors! Why? I am convinced that it would be possible to present these terrific ideas in a much more -ah- "distilled" form. With a "tighter" vocabulary. As it is, I am using a high-concentrate mixture of willpower and espressos to force my way through because I need the insights buried underneath the text.
The book also suffers from poor editing. There is quite a bit of redundancy, and some discussions lack focus. Many of the introductions or summaries to chapters could have been cut in their entirety. I've even found the same sentence repeated just a few paragraphs apart - something that just a single alert proofreader capable of focusing throughout the text should have caught. But it *is* hard to keep that focus.
It is a crying shame, since the underlying ideas and intentions are so good.
July 11, 2020
For some reason this book is greatly beloved in programming circles. I can't tell if that's because the people doing the beloving are die-hard Java Enterprise programmers, or if I'm just missing something here. But I think it's the former.
Domain-Driven Design is an excessively dry, boring book whose main thesis seems to be "make sure everybody agrees on what terminology is being used." What could have been this one sentence is instead 650 pages, chocked full of UML diagrams and insipid discussions about shipping containers. And that's saying something, coming from a guy who reads excessively dry boring math and engineering books on the regular.
If I had to be charitable, I would say that this book is independently groping towards functional programming without knowing it, and trying to shoehorn the ideas into an OOP-mindset. There is a lot of potential here for things to like, but it ultimately falls short. If you've only ever coded in Java, or frequently sketch UML diagrams, this might be the book for you. And if so, may god have mercy on your soul.
Domain-Driven Design is an excessively dry, boring book whose main thesis seems to be "make sure everybody agrees on what terminology is being used." What could have been this one sentence is instead 650 pages, chocked full of UML diagrams and insipid discussions about shipping containers. And that's saying something, coming from a guy who reads excessively dry boring math and engineering books on the regular.
If I had to be charitable, I would say that this book is independently groping towards functional programming without knowing it, and trying to shoehorn the ideas into an OOP-mindset. There is a lot of potential here for things to like, but it ultimately falls short. If you've only ever coded in Java, or frequently sketch UML diagrams, this might be the book for you. And if so, may god have mercy on your soul.
June 13, 2018
It is a quite famous book but I did not enjoy it. I finished the book just because we had been reading it together with my colleagues. There are several interesting poinst but otherwise it is too long. Indeed, summary at InfoQ is available.
January 23, 2020
Amazing book!
Every programmer must read it! As well as Pragmatic Programmer by Dave Thomas and Andy Hunt and Refactoring by Martin Fowler.
There are many books tells you to separate domain logic from other parts like UI and Persitence, because it is the most valuable part of application and you should be able to make changes as quick, as your business changes and as your understanding of domain improves.
But! There are very few books about how to design domain layer of your application!
This is the first of and The Best one!
It is very easy to read DDD, because of excellent language of Eric Evans. Every pattern and principle goes with clear example from real authors practice.
One of my favourite points in the book, that you can never make all requirements and design upfront and write all code right after, unless you are working on very small application, or(and) requirements are as clear as the periodic table of Dmitry Mendeleev. That is because only the code reflects your current understanding of domain model and gives you deeper understanding of directions of improving your model and UBIQUITOUS LANGUAGE. Clear justification of this point is in the book!
I can recommend DDD to every programmer, even with small experience.
The world would be much better if every project (especially enterprise) and product manager also read this book! But unfortunately it is utopia:(
The earlier you read it the happier professional you will become!
Every programmer must read it! As well as Pragmatic Programmer by Dave Thomas and Andy Hunt and Refactoring by Martin Fowler.
There are many books tells you to separate domain logic from other parts like UI and Persitence, because it is the most valuable part of application and you should be able to make changes as quick, as your business changes and as your understanding of domain improves.
But! There are very few books about how to design domain layer of your application!
This is the first of and The Best one!
It is very easy to read DDD, because of excellent language of Eric Evans. Every pattern and principle goes with clear example from real authors practice.
One of my favourite points in the book, that you can never make all requirements and design upfront and write all code right after, unless you are working on very small application, or(and) requirements are as clear as the periodic table of Dmitry Mendeleev. That is because only the code reflects your current understanding of domain model and gives you deeper understanding of directions of improving your model and UBIQUITOUS LANGUAGE. Clear justification of this point is in the book!
I can recommend DDD to every programmer, even with small experience.
The world would be much better if every project (especially enterprise) and product manager also read this book! But unfortunately it is utopia:(
The earlier you read it the happier professional you will become!
October 31, 2019
A good book to read for any coder. The ratio of time spent reading vs. writing is well over 10:1.
February 17, 2021
I'd heard about domain-driven design and had read about that here and there, and I wanted to know more. So, I picked up this book.
Disappointingly, reading it was a very painful experience. Ideas were scattered and lacked focus. Examples were unnecessarily complicated and lacked enough context to be educational. Sentences were repeated and repeated again without adding much value. The whole idea of the book could be simply presented in a blog post.
If you're like me and want to know more about domain-driven design, just read some blog posts on the topic, or watch some recordings of conferences regarding the concept. It saves your time and you can learn much more.
Disappointingly, reading it was a very painful experience. Ideas were scattered and lacked focus. Examples were unnecessarily complicated and lacked enough context to be educational. Sentences were repeated and repeated again without adding much value. The whole idea of the book could be simply presented in a blog post.
If you're like me and want to know more about domain-driven design, just read some blog posts on the topic, or watch some recordings of conferences regarding the concept. It saves your time and you can learn much more.
November 11, 2021
Ironic how a book that advocates concise documentation and diagrams over text looses itself in way too much narrative. The ideas in this book are good, but it could have easily been half as long. It keeps on repeating itself in long paragraphs, full of vague terms.
The used examples are realistic (all coming from real projects), but sometimes lacked context to understand the reasoning that was applied to apply the patterns.
The used examples are realistic (all coming from real projects), but sometimes lacked context to understand the reasoning that was applied to apply the patterns.
April 9, 2013
While reading this book I complained a lot about the author repeating the same ideas supported by different examples. However, I really enjoyed reading it and I feel I gained a lot of knowledge about designing software applications. Of course, this knowledge is purely theoretical, but we all have to start somewhere.
One thing I really appreciated is that the author doesn’t isolate the design and development part from the human interaction. One has to know the team members’ skills and employ them as efficiently as possible in the software development process. The main idea he tries to promote is knowing your domain and making your code express that domain.
This book does not offer recipes for designing and developing software applications, but provides a series of guidelines that one can follow and/or adapt to a certain project.
I think it’s quite a valuable book to read, although it might arise some developer mixed feelings about the author giving exhaustive examples and explanations in some cases. It is always a pleasure to read a book that has behind it a lot of experience in software development and also in applying domain driven design principles throughout one’s work.
One thing I really appreciated is that the author doesn’t isolate the design and development part from the human interaction. One has to know the team members’ skills and employ them as efficiently as possible in the software development process. The main idea he tries to promote is knowing your domain and making your code express that domain.
This book does not offer recipes for designing and developing software applications, but provides a series of guidelines that one can follow and/or adapt to a certain project.
I think it’s quite a valuable book to read, although it might arise some developer mixed feelings about the author giving exhaustive examples and explanations in some cases. It is always a pleasure to read a book that has behind it a lot of experience in software development and also in applying domain driven design principles throughout one’s work.
February 3, 2013
Actually, it's the 2nd time I've read that book. After the 1st time I was quite happy with what I've received - I've generally agreed to author's approach, even more: I've found it rather obvious ("so not a big deal") - I'd do pretty much the same in the example cases, I agree that those design decisions are more reasonable, etc.
Some time has passed, I've discussed DDD with several people on several occassions and I think now I got the value of this book: author does not only gives you the example of good design, but he provides you the rules / formulas how to achieve that. I didn't see that when I was reading DDD for the first time, because I'm doing design "automatically" / intuitively, so I've never really needed those rules (and I've ignored them, to put it bluntly).
But I have a problem with teaching people how to make a good design, how to make a difference between snapshotting reality and making a proper model. And here's where this book really excels, this is the first book I've seen that actually CAN make reader a better designed. Very recommended.
Some time has passed, I've discussed DDD with several people on several occassions and I think now I got the value of this book: author does not only gives you the example of good design, but he provides you the rules / formulas how to achieve that. I didn't see that when I was reading DDD for the first time, because I'm doing design "automatically" / intuitively, so I've never really needed those rules (and I've ignored them, to put it bluntly).
But I have a problem with teaching people how to make a good design, how to make a difference between snapshotting reality and making a proper model. And here's where this book really excels, this is the first book I've seen that actually CAN make reader a better designed. Very recommended.
July 15, 2018
This book is a fundamental one in the shelf of every software developer who tends overcome the difficulty of creating complex software in a maintainable fashion.
June 16, 2021
Far too long, generic to the point where it doesn't really say anything, ideas in it are not too far from trivial.
There are a lot of positive reviews for this book, and I started reading it because I saw them, and because I also saw recommendation for this book in a lot of other books that I read. However now that I finished it, I think it is the most overrated book I read.
So why am I so different from the majority here? Why do I consider this book to be a waste of one's time, when so many smart people think it's good?
The good:
I think this book is "a classic" in the sense that when it was written, 16 years ago (wild speculations coming up), I am imagining these types of phenomena were going on:
1. Java was a new thing
2. Big systems are built with Java
3. Big systems require architects
4. Software architecture was a category which sold books quite well
5. It's possible a lot of people were writing stuff about UML and concrete patterns
...so this book was written on a niche topic, in a niche way, so to stand out form the crowd.
1. Topic = "the domain model"
2. The way = "be very generic, talk about things in new ways, talk about very high level things, and about things other people aren't writing". I am a big fan of talking concretely, so I will explain these terms. By "talk about things in new ways" I mean that he wrote about the good old factory pattern, but also introduced 2 accompanying concepts: services and repositories. Sure, one could argue a lot about whether those could be considered factories or not. I don't have a strong opinion, but I like the distinction, even though those 3 concepts do resemble a lot. In any case, the discussion about factories/services/repositories is one which, in my opinion, is just a way to fill up a book with text that brings very little value. You must understand that the author spends dozens of pages comparing these 3 concepts in a way I'll call innovative repetition: He does say the same thing, he just uses slightly different words. Also each time he does it, he presents slightly more information, which he then repeats in subsequent paragraphs. The guy's an artist at this, but I was neither expecting nor wanting to read a book for the artistic impact it might have on me.
Same thing for "talking about very high level things": here the author talks about "large scale structures". He talks about frameworks, system metaphors, bounded contexts, conformist pattern, anticorruption layers and more stuff like this. This might have brought some fresh air into the discussions in 2005, but for some reason, I find very little value here for anyone. The value of these ideas is the same value a fish would get, when another fish told it they were living in water. Sure, it's kind of mind-blowing to realise that layers are a choice, that duplicating work is not necessarily bad, and that it's good to have some (any!) way of talking about your system, but really it's very far from an actionable idea. Maybe this book would be good for people who haven't studied communication, and haven't really thought about how to present software systems to other people. But if I could use an analogy, the value of these ideas is like the first time someone invented a city name place. Sure, it's a very useful thing for someone coming into the city, to know the city name, but it's far from groundbreaking.
Let me randomly write here about some ideas I found interesting. I took a lot of notes, but a lot of them are to refute the idea. Anyway:
1. To make the domain less complicated, functions/methods should take as parameters, or return either simple things (basic data types) or instances of the class defining that method. Example: `colour3 = colour1.mixWith(colour2)`.
2. Side-effect-free functions are good (that's almost common knowledge nowadays)
3. If you mutate state with a function, surround the mutation with `assertions`. Good practice really!
4. Read the book "Analysis Patterns" (Martin Fowler)
5. Apparently "good developers" tend to use their skills in setting up infrastructure, whereas the less skilled ones end up working on the domain. Does seem familiar, yes.
6. Sometimes architecture can impact a project negatively. It can lead to "developers fighting architects". Not too interesting, but does make some sense.
7. Layers: Potential, Operational, Commitments (contractual), Policies (legal requirements/business decisions), Decision support (analytics). Good ideas!
8. To give a large system some structure, one could apply "softer" or "harder" constraints on it. Going from soft to hard: System metaphor (a story about what that component is supposed to do), Layers, Pluggable component framework.
Some additional aspects worth mentioning: Maybe, just maybe, the patterns in this book have influenced the industry so profoundly, that I can't even realise it. Examples:
1. People paying attention to the domain might have influenced the move towards microservices. Maybe this is how people of 2021 are trying to implement bounded contexts.
2. The repository pattern is very widespread now. Sure, it's kind of a trivial pattern if you look at it with from 2021, but maybe 20 years ago people were structuring their codebases totally differently. I wouldn't know. Maybe the ORMs were supposed to be "the domain" layer, but they're definitely not JUST what the author describes, as they contain both business and persistence logic.
So I can understand that there could be people who get value out of this, but I personally have not gained too much. You should also know that I was struggling really hard to write positive things about the book. I went through all ~100 notes to find good ideas, and all I found good is listed here. I did NOT go through my notes to write about the bad/ugly parts, so maybe this review is too positive.
The bad:
More bad stuff: The author prepares the stage a lot for concepts he'll eventually exemplify. A lot of times however, the code doesn't seem to prove his point too much. He realises that, and ends sub-chapters with advice like "this is no silver bullet, you'll have to experiment for yourself, this problem rarely helps". That's fair as a disclaimer, but most of the time I found the concepts to be so vague and examples so useless that I wondered if really they were worth reading about. I'm sure a lot of intelligent people already realise that experimentation is useful, and situations tend to be unique. It feels like he's not doing too much above "preaching to the choir".
The ugly:
1. Wordpres! It just got 40% of the CMS market recently. Developers I talked to say it's one of the ugliest pieces of software ever written. It's horrible to be a developer and work on that. The value of this book is highly arguable when you see someone literally urinating on top of all software architecture literature, and then being rewarded by the market for it. Someone please correct me if I'm wrong.
2. django! One of the many web frameworks which uses fewer layers than this book would suggest. People use it, it's fine, it works for small/medium websites just fine!
You never get a feeling of how bad/good something is from this book. You just get qualitative "this is a better way" comparison. I'm getting the feeling that if the author would have honestly evaluated the advice he gave, this book wouldn't be nearly as famous. As it is, I think he simply uses scare tactics, to frighten people into "architecting everything". I would have loved it to read things like: "In 2-people teams, working for 3 years on a project, you don't need any large scale architecture", "in a 20-people team working for 10 years, you will find it highly desirable to use system metaphors", or "When the domain comprises less than 50 entities, you're fine to not use any patterns". My remarks might be trivial, yes, but I don't think enough people realise the scale at which you have to begin fearing the software. This creates a large gap in the heads of beginners between theory and reality. I think even beginners should realise that if you want to travel 2 meters, you walk on foot, but if you need to travel 3k kilometers, you take the airplane. This information is missing, and I think authors might be purposefully over-selling their airplane-ideas, hurting the industry and enriching themselves - maybe I'm too paranoid, but there it is. Would authors have an incentive to over-sell their skills? Yes! Should they address the conflict of interest? Yes. Did the author of this book address the issue? No....
I do not recommend this book.
There are a lot of positive reviews for this book, and I started reading it because I saw them, and because I also saw recommendation for this book in a lot of other books that I read. However now that I finished it, I think it is the most overrated book I read.
So why am I so different from the majority here? Why do I consider this book to be a waste of one's time, when so many smart people think it's good?
The good:
I think this book is "a classic" in the sense that when it was written, 16 years ago (wild speculations coming up), I am imagining these types of phenomena were going on:
1. Java was a new thing
2. Big systems are built with Java
3. Big systems require architects
4. Software architecture was a category which sold books quite well
5. It's possible a lot of people were writing stuff about UML and concrete patterns
...so this book was written on a niche topic, in a niche way, so to stand out form the crowd.
1. Topic = "the domain model"
2. The way = "be very generic, talk about things in new ways, talk about very high level things, and about things other people aren't writing". I am a big fan of talking concretely, so I will explain these terms. By "talk about things in new ways" I mean that he wrote about the good old factory pattern, but also introduced 2 accompanying concepts: services and repositories. Sure, one could argue a lot about whether those could be considered factories or not. I don't have a strong opinion, but I like the distinction, even though those 3 concepts do resemble a lot. In any case, the discussion about factories/services/repositories is one which, in my opinion, is just a way to fill up a book with text that brings very little value. You must understand that the author spends dozens of pages comparing these 3 concepts in a way I'll call innovative repetition: He does say the same thing, he just uses slightly different words. Also each time he does it, he presents slightly more information, which he then repeats in subsequent paragraphs. The guy's an artist at this, but I was neither expecting nor wanting to read a book for the artistic impact it might have on me.
Same thing for "talking about very high level things": here the author talks about "large scale structures". He talks about frameworks, system metaphors, bounded contexts, conformist pattern, anticorruption layers and more stuff like this. This might have brought some fresh air into the discussions in 2005, but for some reason, I find very little value here for anyone. The value of these ideas is the same value a fish would get, when another fish told it they were living in water. Sure, it's kind of mind-blowing to realise that layers are a choice, that duplicating work is not necessarily bad, and that it's good to have some (any!) way of talking about your system, but really it's very far from an actionable idea. Maybe this book would be good for people who haven't studied communication, and haven't really thought about how to present software systems to other people. But if I could use an analogy, the value of these ideas is like the first time someone invented a city name place. Sure, it's a very useful thing for someone coming into the city, to know the city name, but it's far from groundbreaking.
Let me randomly write here about some ideas I found interesting. I took a lot of notes, but a lot of them are to refute the idea. Anyway:
1. To make the domain less complicated, functions/methods should take as parameters, or return either simple things (basic data types) or instances of the class defining that method. Example: `colour3 = colour1.mixWith(colour2)`.
2. Side-effect-free functions are good (that's almost common knowledge nowadays)
3. If you mutate state with a function, surround the mutation with `assertions`. Good practice really!
4. Read the book "Analysis Patterns" (Martin Fowler)
5. Apparently "good developers" tend to use their skills in setting up infrastructure, whereas the less skilled ones end up working on the domain. Does seem familiar, yes.
6. Sometimes architecture can impact a project negatively. It can lead to "developers fighting architects". Not too interesting, but does make some sense.
7. Layers: Potential, Operational, Commitments (contractual), Policies (legal requirements/business decisions), Decision support (analytics). Good ideas!
8. To give a large system some structure, one could apply "softer" or "harder" constraints on it. Going from soft to hard: System metaphor (a story about what that component is supposed to do), Layers, Pluggable component framework.
Some additional aspects worth mentioning: Maybe, just maybe, the patterns in this book have influenced the industry so profoundly, that I can't even realise it. Examples:
1. People paying attention to the domain might have influenced the move towards microservices. Maybe this is how people of 2021 are trying to implement bounded contexts.
2. The repository pattern is very widespread now. Sure, it's kind of a trivial pattern if you look at it with from 2021, but maybe 20 years ago people were structuring their codebases totally differently. I wouldn't know. Maybe the ORMs were supposed to be "the domain" layer, but they're definitely not JUST what the author describes, as they contain both business and persistence logic.
So I can understand that there could be people who get value out of this, but I personally have not gained too much. You should also know that I was struggling really hard to write positive things about the book. I went through all ~100 notes to find good ideas, and all I found good is listed here. I did NOT go through my notes to write about the bad/ugly parts, so maybe this review is too positive.
The bad:
More bad stuff: The author prepares the stage a lot for concepts he'll eventually exemplify. A lot of times however, the code doesn't seem to prove his point too much. He realises that, and ends sub-chapters with advice like "this is no silver bullet, you'll have to experiment for yourself, this problem rarely helps". That's fair as a disclaimer, but most of the time I found the concepts to be so vague and examples so useless that I wondered if really they were worth reading about. I'm sure a lot of intelligent people already realise that experimentation is useful, and situations tend to be unique. It feels like he's not doing too much above "preaching to the choir".
The ugly:
1. Wordpres! It just got 40% of the CMS market recently. Developers I talked to say it's one of the ugliest pieces of software ever written. It's horrible to be a developer and work on that. The value of this book is highly arguable when you see someone literally urinating on top of all software architecture literature, and then being rewarded by the market for it. Someone please correct me if I'm wrong.
2. django! One of the many web frameworks which uses fewer layers than this book would suggest. People use it, it's fine, it works for small/medium websites just fine!
You never get a feeling of how bad/good something is from this book. You just get qualitative "this is a better way" comparison. I'm getting the feeling that if the author would have honestly evaluated the advice he gave, this book wouldn't be nearly as famous. As it is, I think he simply uses scare tactics, to frighten people into "architecting everything". I would have loved it to read things like: "In 2-people teams, working for 3 years on a project, you don't need any large scale architecture", "in a 20-people team working for 10 years, you will find it highly desirable to use system metaphors", or "When the domain comprises less than 50 entities, you're fine to not use any patterns". My remarks might be trivial, yes, but I don't think enough people realise the scale at which you have to begin fearing the software. This creates a large gap in the heads of beginners between theory and reality. I think even beginners should realise that if you want to travel 2 meters, you walk on foot, but if you need to travel 3k kilometers, you take the airplane. This information is missing, and I think authors might be purposefully over-selling their airplane-ideas, hurting the industry and enriching themselves - maybe I'm too paranoid, but there it is. Would authors have an incentive to over-sell their skills? Yes! Should they address the conflict of interest? Yes. Did the author of this book address the issue? No....
I do not recommend this book.
October 29, 2009
Great, great book. However, you should probably have at least some understanding of agile, design patterns, and refactoring before reading this book if you truly want to get the most out of it. The book talks about using model-driven design to create a domain model and ubiquitous language that everyone in the company can leverage - a topic that seems to be getting more attention as of late.
Some of the topics are pretty abstract, and I would have liked to see some more code and concrete examples for some of them. Nonetheless, I encourage all programmers to at least read chapters 1-3, 5, 6, 9, 10, and 14.
Some of the topics are pretty abstract, and I would have liked to see some more code and concrete examples for some of them. Nonetheless, I encourage all programmers to at least read chapters 1-3, 5, 6, 9, 10, and 14.
March 12, 2016
Please take this with grain of salt; most of my reading of this book was fast reading.
What I like about this book is that there is a genuine trial to bring examples to the various concepts. This is done throughout the book.
What I don't like:
- Too much repetition and too verbose
- I feel that the statements are structured in a way that makes it really hard for fast reading
- Even with examples, sometimes I feel it's too much theory
What I like about this book is that there is a genuine trial to bring examples to the various concepts. This is done throughout the book.
What I don't like:
- Too much repetition and too verbose
- I feel that the statements are structured in a way that makes it really hard for fast reading
- Even with examples, sometimes I feel it's too much theory
November 26, 2016
Bardzo ważna, ale niestety równie fatalnie (a przynajmniej nieprzystępnie) napisana książka - językowo blisko jej do pracy naukowej. Na pewno nie na początek z DDD.
November 26, 2016
very valid concept
but, omg, so painful to read
I am not sure what is wrong with it, but I just couldn't finish it. It's boring, long-winded and just hard work...
I can't really recommended. I mean the concepts are all valid, but I'd rather go for a summary...
I am not sure this topic justifies 516 pages...
For those who are interested, this goes will with
Implementing Domain-Driven Design
And this seems to be a shorter summary (though I have not read it yet myself):
Domain-Driven Design Distilled
but, omg, so painful to read
I am not sure what is wrong with it, but I just couldn't finish it. It's boring, long-winded and just hard work...
I can't really recommended. I mean the concepts are all valid, but I'd rather go for a summary...
I am not sure this topic justifies 516 pages...
For those who are interested, this goes will with
Implementing Domain-Driven Design
And this seems to be a shorter summary (though I have not read it yet myself):
Domain-Driven Design Distilled
November 15, 2023
Far too long, generic to the point where it doesn't really say anything, ideas in it are not too far from trivial.
There are a lot of positive reviews for this book, and I started reading it because I saw them, and because I also saw recommendation for this book in a lot of other books that I read. However now that I finished it, I think it is the most overrated book I read.
So why am I so different from the majority here? Why do I consider this book to be a waste of one's time, when so many smart people think it's good?
The good:
I think this book is "a classic" in the sense that when it was written, 16 years ago (wild speculations coming up), I am imagining these types of phenomena were going on:
1. Java was a new thing
2. Big systems are built with Java
3. Big systems require architects
4. Software architecture was a category which sold books quite well
5. It's possible a lot of people were writing stuff about UML and concrete patterns
...so this book was written on a niche topic, in a niche way, so to stand out form the crowd.
1. Topic = "the domain model"
2. The way = "be very generic, talk about things in new ways, talk about very high level things, and about things other people aren't writing". I am a big fan of talking concretely, so I will explain these terms. By "talk about things in new ways" I mean that he wrote about the good old factory pattern, but also introduced 2 accompanying concepts: services and repositories. Sure, one could argue a lot about whether those could be considered factories or not. I don't have a strong opinion, but I like the distinction, even though those 3 concepts do resemble a lot. In any case, the discussion about factories/services/repositories is one which, in my opinion, is just a way to fill up a book with text that brings very little value. You must understand that the author spends dozens of pages comparing these 3 concepts in a way I'll call innovative repetition: He does say the same thing, he just uses slightly different words. Also each time he does it, he presents slightly more information, which he then repeats in subsequent paragraphs. The guy's an artist at this, but I was neither expecting nor wanting to read a book for the artistic impact it might have on me.
Same thing for "talking about very high level things": here the author talks about "large scale structures". He talks about frameworks, system metaphors, bounded contexts, conformist pattern, anticorruption layers and more stuff like this. This might have brought some fresh air into the discussions in 2005, but for some reason, I find very little value here for anyone. The value of these ideas is the same value a fish would get, when another fish told it they were living in water. Sure, it's kind of mind-blowing to realise that layers are a choice, that duplicating work is not necessarily bad, and that it's good to have some (any!) way of talking about your system, but really it's very far from an actionable idea. Maybe this book would be good for people who haven't studied communication, and haven't really thought about how to present software systems to other people. But if I could use an analogy, the value of these ideas is like the first time someone invented a city name place. Sure, it's a very useful thing for someone coming into the city, to know the city name, but it's far from groundbreaking.
Let me randomly write here about some ideas I found interesting. I took a lot of notes, but a lot of them are to refute the idea. Anyway:
1. To make the domain less complicated, functions/methods should take as parameters, or return either simple things (basic data types) or instances of the class defining that method. Example: `colour3 = colour1.mixWith(colour2)`.
2. Side-effect-free functions are good (that's almost common knowledge nowadays)
3. If you mutate state with a function, surround the mutation with `assertions`. Good practice really!
4. Read the book "Analysis Patterns" (Martin Fowler)
5. Apparently "good developers" tend to use their skills in setting up infrastructure, whereas the less skilled ones end up working on the domain. Does seem familiar, yes.
6. Sometimes architecture can impact a project negatively. It can lead to "developers fighting architects". Not too interesting, but does make some sense.
7. Layers: Potential, Operational, Commitments (contractual), Policies (legal requirements/business decisions), Decision support (analytics). Good ideas!
8. To give a large system some structure, one could apply "softer" or "harder" constraints on it. Going from soft to hard: System metaphor (a story about what that component is supposed to do), Layers, Pluggable component framework.
Some additional aspects worth mentioning: Maybe, just maybe, the patterns in this book have influenced the industry so profoundly, that I can't even realise it. Examples:
1. People paying attention to the domain might have influenced the move towards microservices. Maybe this is how people of 2021 are trying to implement bounded contexts.
2. The repository pattern is very widespread now. Sure, it's kind of a trivial pattern if you look at it with from 2021, but maybe 20 years ago people were structuring their codebases totally differently. I wouldn't know. Maybe the ORMs were supposed to be "the domain" layer, but they're definitely not JUST what the author describes, as they contain both business and persistence logic.
So I can understand that there could be people who get value out of this, but I personally have not gained too much. You should also know that I was struggling really hard to write positive things about the book. I went through all ~100 notes to find good ideas, and all I found good is listed here. I did NOT go through my notes to write about the bad/ugly parts, so maybe this review is too positive.
The bad:
More bad stuff: The author prepares the stage a lot for concepts he'll eventually exemplify. A lot of times however, the code doesn't seem to prove his point too much. He realises that, and ends sub-chapters with advice like "this is no silver bullet, you'll have to experiment for yourself, this problem rarely helps". That's fair as a disclaimer, but most of the time I found the concepts to be so vague and examples so useless that I wondered if really they were worth reading about. I'm sure a lot of intelligent people already realise that experimentation is useful, and situations tend to be unique. It feels like he's not doing too much above "preaching to the choir".
The ugly:
1. Wordpres! It just got 40% of the CMS market recently. Developers I talked to say it's one of the ugliest pieces of software ever written. It's horrible to be a developer and work on that. The value of this book is highly arguable when you see someone literally urinating on top of all software architecture literature, and then being rewarded by the market for it. Someone please correct me if I'm wrong.
2. django! One of the many web frameworks which uses fewer layers than this book would suggest. People use it, it's fine, it works for small/medium websites just fine!
You never get a feeling of how bad/good something is from this book. You just get qualitative "this is a better way" comparison. I'm getting the feeling that if the author would have honestly evaluated the advice he gave, this book wouldn't be nearly as famous. As it is, I think he simply uses scare tactics, to frighten people into "architecting everything". I would have loved it to read things like: "In 2-people teams, working for 3 years on a project, you don't need any large scale architecture", "in a 20-people team working for 10 years, you will find it highly desirable to use system metaphors", or "When the domain comprises less than 50 entities, you're fine to not use any patterns". My remarks might be trivial, yes, but I don't think enough people realise the scale at which you have to begin fearing the software. This creates a large gap in the heads of beginners between theory and reality. I think even beginners should realise that if you want to travel 2 meters, you walk on foot, but if you need to travel 3k kilometers, you take the airplane. This information is missing, and I think authors might be purposefully over-selling their airplane-ideas, hurting the industry and enriching themselves - maybe I'm too paranoid, but there it is. Would authors have an incentive to over-sell their skills? Yes! Should they address the conflict of interest? Yes. Did the author of this book address the issue? No....
I do not recommend this book.
There are a lot of positive reviews for this book, and I started reading it because I saw them, and because I also saw recommendation for this book in a lot of other books that I read. However now that I finished it, I think it is the most overrated book I read.
So why am I so different from the majority here? Why do I consider this book to be a waste of one's time, when so many smart people think it's good?
The good:
I think this book is "a classic" in the sense that when it was written, 16 years ago (wild speculations coming up), I am imagining these types of phenomena were going on:
1. Java was a new thing
2. Big systems are built with Java
3. Big systems require architects
4. Software architecture was a category which sold books quite well
5. It's possible a lot of people were writing stuff about UML and concrete patterns
...so this book was written on a niche topic, in a niche way, so to stand out form the crowd.
1. Topic = "the domain model"
2. The way = "be very generic, talk about things in new ways, talk about very high level things, and about things other people aren't writing". I am a big fan of talking concretely, so I will explain these terms. By "talk about things in new ways" I mean that he wrote about the good old factory pattern, but also introduced 2 accompanying concepts: services and repositories. Sure, one could argue a lot about whether those could be considered factories or not. I don't have a strong opinion, but I like the distinction, even though those 3 concepts do resemble a lot. In any case, the discussion about factories/services/repositories is one which, in my opinion, is just a way to fill up a book with text that brings very little value. You must understand that the author spends dozens of pages comparing these 3 concepts in a way I'll call innovative repetition: He does say the same thing, he just uses slightly different words. Also each time he does it, he presents slightly more information, which he then repeats in subsequent paragraphs. The guy's an artist at this, but I was neither expecting nor wanting to read a book for the artistic impact it might have on me.
Same thing for "talking about very high level things": here the author talks about "large scale structures". He talks about frameworks, system metaphors, bounded contexts, conformist pattern, anticorruption layers and more stuff like this. This might have brought some fresh air into the discussions in 2005, but for some reason, I find very little value here for anyone. The value of these ideas is the same value a fish would get, when another fish told it they were living in water. Sure, it's kind of mind-blowing to realise that layers are a choice, that duplicating work is not necessarily bad, and that it's good to have some (any!) way of talking about your system, but really it's very far from an actionable idea. Maybe this book would be good for people who haven't studied communication, and haven't really thought about how to present software systems to other people. But if I could use an analogy, the value of these ideas is like the first time someone invented a city name place. Sure, it's a very useful thing for someone coming into the city, to know the city name, but it's far from groundbreaking.
Let me randomly write here about some ideas I found interesting. I took a lot of notes, but a lot of them are to refute the idea. Anyway:
1. To make the domain less complicated, functions/methods should take as parameters, or return either simple things (basic data types) or instances of the class defining that method. Example: `colour3 = colour1.mixWith(colour2)`.
2. Side-effect-free functions are good (that's almost common knowledge nowadays)
3. If you mutate state with a function, surround the mutation with `assertions`. Good practice really!
4. Read the book "Analysis Patterns" (Martin Fowler)
5. Apparently "good developers" tend to use their skills in setting up infrastructure, whereas the less skilled ones end up working on the domain. Does seem familiar, yes.
6. Sometimes architecture can impact a project negatively. It can lead to "developers fighting architects". Not too interesting, but does make some sense.
7. Layers: Potential, Operational, Commitments (contractual), Policies (legal requirements/business decisions), Decision support (analytics). Good ideas!
8. To give a large system some structure, one could apply "softer" or "harder" constraints on it. Going from soft to hard: System metaphor (a story about what that component is supposed to do), Layers, Pluggable component framework.
Some additional aspects worth mentioning: Maybe, just maybe, the patterns in this book have influenced the industry so profoundly, that I can't even realise it. Examples:
1. People paying attention to the domain might have influenced the move towards microservices. Maybe this is how people of 2021 are trying to implement bounded contexts.
2. The repository pattern is very widespread now. Sure, it's kind of a trivial pattern if you look at it with from 2021, but maybe 20 years ago people were structuring their codebases totally differently. I wouldn't know. Maybe the ORMs were supposed to be "the domain" layer, but they're definitely not JUST what the author describes, as they contain both business and persistence logic.
So I can understand that there could be people who get value out of this, but I personally have not gained too much. You should also know that I was struggling really hard to write positive things about the book. I went through all ~100 notes to find good ideas, and all I found good is listed here. I did NOT go through my notes to write about the bad/ugly parts, so maybe this review is too positive.
The bad:
More bad stuff: The author prepares the stage a lot for concepts he'll eventually exemplify. A lot of times however, the code doesn't seem to prove his point too much. He realises that, and ends sub-chapters with advice like "this is no silver bullet, you'll have to experiment for yourself, this problem rarely helps". That's fair as a disclaimer, but most of the time I found the concepts to be so vague and examples so useless that I wondered if really they were worth reading about. I'm sure a lot of intelligent people already realise that experimentation is useful, and situations tend to be unique. It feels like he's not doing too much above "preaching to the choir".
The ugly:
1. Wordpres! It just got 40% of the CMS market recently. Developers I talked to say it's one of the ugliest pieces of software ever written. It's horrible to be a developer and work on that. The value of this book is highly arguable when you see someone literally urinating on top of all software architecture literature, and then being rewarded by the market for it. Someone please correct me if I'm wrong.
2. django! One of the many web frameworks which uses fewer layers than this book would suggest. People use it, it's fine, it works for small/medium websites just fine!
You never get a feeling of how bad/good something is from this book. You just get qualitative "this is a better way" comparison. I'm getting the feeling that if the author would have honestly evaluated the advice he gave, this book wouldn't be nearly as famous. As it is, I think he simply uses scare tactics, to frighten people into "architecting everything". I would have loved it to read things like: "In 2-people teams, working for 3 years on a project, you don't need any large scale architecture", "in a 20-people team working for 10 years, you will find it highly desirable to use system metaphors", or "When the domain comprises less than 50 entities, you're fine to not use any patterns". My remarks might be trivial, yes, but I don't think enough people realise the scale at which you have to begin fearing the software. This creates a large gap in the heads of beginners between theory and reality. I think even beginners should realise that if you want to travel 2 meters, you walk on foot, but if you need to travel 3k kilometers, you take the airplane. This information is missing, and I think authors might be purposefully over-selling their airplane-ideas, hurting the industry and enriching themselves - maybe I'm too paranoid, but there it is. Would authors have an incentive to over-sell their skills? Yes! Should they address the conflict of interest? Yes. Did the author of this book address the issue? No....
I do not recommend this book.
September 5, 2020
معلومات الكتاب
--------
الكتاب يعرف أيضا بالكتاب الأزرق (The blue book)
اسم المؤلف: إريك إيفانز Eric Evans
دار النشر: Addison-Wesley Professional
سنة النشر: 2003
عدد الصفحات: 563
التقييم: 4 من 5
المستوى: متقدم
.
موضوعات الكتاب
----------
هذا هو الكتاب المؤسس للـ Domain-Driven Design وأول كتاب أُلف في الموضوع، وأفكار الكتاب هي امتداد لأفكار أخرى مثل الـ Object-Oriented Design و الExtreme Programming وال Design By Contract وال Analysis Patterns وغيرها.
الهدف من الDomain-Driven Design هو السيطرة على هذه التعقيدات والصعوبات المصاحبة لعملية صناعة البرمجيات. كيف ذاك؟
بالتركيز على مجال العمل (Business Domain) وعزله عن المجالات المصاحبة أو المساعدة، وكذلك عزله عن اللوازم التقنية الضرورية للنمذجة، أي تحويل مجال العمل إلى برنامج. وهذه النمذجة هذه هي الفكرة الأولى في الDomain-Driven Design، ويمكن تسميتها الDomain Modeling، وامتداد هذه الفكرة هو استخدام نموذج واحد في التحليل والتصميم وتطبيق هذا النموذج في التنفيذ (الكود)، وهذه الفكرة تسمى Model-Driven Design.
ولإيجاد هذه النموذج الموحد، وجدت الحاجة لإيجاد لغة موحدة في التواصل بين المطورين والمحللين والمتخصصين في المجال (Domain Experts) وكل ذوي العلاقة بالمشروع، وهذه اللغة تستخدم كذلك في جميع الوثائق المتعلقة بالمشروع وفي الكود والشاشات وفي كل مكان ذي صلة بالمشروع، وهذه يمكن تسميتها Ubiquitous Language (وتنطق هكذا يوبيك-وي-طاص). وهذه في الفكرة الثانية في الـ Domain-Driven Design.
الفكرة الثالثة هي التدرج والتواصل المستمر بين كل ذوي العلاقة بالمشروع لفهم مجال العمل وتحسين نموذج البرنامج وعمليات التصميم والتطوير.
هذه هي الأفكار الرئيسية في الجزء الأول من الكتاب، ومنها انبثقت بقية أفكاره.
في الجزء الثاني من الكتاب توسع المؤلف في الModel-Driven Design، فتحدث عن فكرة فصل أو عزل نموذج مجال العمال (Business Domain) ثم استعرض أنماط التصميم (Design Patterns) ذات الصلة مثل الEntities و الValue Objects وال Aggregates و ال Repositories وغيرها، وهذه الأنماط مشهورة وشائعة في أدبيات الDomain-Driven Design، حتى يظن كثير من الناس أن أنماط التصميم هذه هي ال Domain-Driven Design، وهذا من الأغلاط الشائعة، في حين أن كل الحديث عنها لم يتجاوز ثلاثة فصول من الكتاب من أصل 17 فصلا! من الأغلاط الشائعة أيضا الاعتقاد أن الDomain-Driven Design لا تطبق إلا عن طريق ال Object Oriented Programming/Design - كما قد توحي أنماط التصميم هذه، وهذا خطأ أيضا، فأي طريقة تؤدي إلى إيجاد نموذج موحد يمكن تطبيقه برمجيا جاز استعماله، ومن هذه النماذج: الWorkflow أو الـ Rule Engines، ومؤخرا صار التنفيذ باستخدام الfunctional paradigms شائعا أيضا.
الجزء الثالث من الكتاب هو الذي استمتعت به أكثر شيء، ويتكلم عن ضرورة فهم مجال العمل ووسائل تحقيق هذا الفهم، وأهمها التدرج والتحسين أو إعادة البناء المستمر (continuous refactoring)، ولا يُكتفي بذلك في الكود فقط، بل في نموذج مجال العمل أيضا (model refactoring)، إضافة إلى مبادئ نافعة في تصميم البرمجيات.
وفي الجزء الرابع والأخير، يتكلم الكتاب عن مبادئ التعامل مع مجالات العمل الضخمة، بالغة التعقيد، والتي تتطلب تكامل بين أنظمة وفرق مختلفة. ولا يُذكر التكامل إلا و يذكر معه تقاطع التقنية مع السياسة! ومن الأفكار التي وردت في هذا القسم: تقسيم مجال العمل إلى مجالات أساسية (Core Subdomain) ومجالات فرعية، وتطبيق ذلك على الBounded Contexts أو مجال تطبيق اللغة المشتركة المذكورة آنفا، وال Context Maps أي العلاقة بين الBounded Contexts المختلفة، وما يتفرع عن هذه الأفكار - وهو كثير، حيث يستغرق هذا الجزء وحده أكثر من ثلث الكتاب! -، وكذلك الكلام على التدرج في المعمارية (Evolutionary Architecture) - وإن لم ترد بهذا الاسم في الكتاب -
.
ملاحظات عامة على الكتاب
------------
المؤلف يحكي الكثير من التجارب الشخصية الناجحة والفاشلة وهذا يعطي مصداقية لكلامه.
الكتاب يبدأ بالتفاصيل ثم يتدرج للصورة الكلية (bottom-up) لكن أهمية الأفكار في الكتاب - من وجهة نظري -هي بعكس هذا الترتيب.
الكتاب دسم جدا ومليء بالأفكار الملهمة، ولذلك لا يصلح للمبتدئين، وعلى الرغم من ذكره بعض الأمثلة التطبيقية لكنها لا تكفي لتمكينك من تطبيق كل هذه الافكار بنفسك.
.
اقتباسات من الكتاب
----------
Manufacturing is a popular metaphor for software development. One inference from this metaphor: highly skilled engineers design; less skilled laborers assemble the products. This metaphor has messed up a lot of projects for one simple reason—software development is all design. All teams have specialized roles for members, but over-separation of responsibility for analysis, modeling, design, and programming interferes with MODEL-DRIVEN DESIGN.
--------
الكتاب يعرف أيضا بالكتاب الأزرق (The blue book)
اسم المؤلف: إريك إيفانز Eric Evans
دار النشر: Addison-Wesley Professional
سنة النشر: 2003
عدد الصفحات: 563
التقييم: 4 من 5
المستوى: متقدم
.
موضوعات الكتاب
----------
هذا هو الكتاب المؤسس للـ Domain-Driven Design وأول كتاب أُلف في الموضوع، وأفكار الكتاب هي امتداد لأفكار أخرى مثل الـ Object-Oriented Design و الExtreme Programming وال Design By Contract وال Analysis Patterns وغيرها.
الهدف من الDomain-Driven Design هو السيطرة على هذه التعقيدات والصعوبات المصاحبة لعملية صناعة البرمجيات. كيف ذاك؟
بالتركيز على مجال العمل (Business Domain) وعزله عن المجالات المصاحبة أو المساعدة، وكذلك عزله عن اللوازم التقنية الضرورية للنمذجة، أي تحويل مجال العمل إلى برنامج. وهذه النمذجة هذه هي الفكرة الأولى في الDomain-Driven Design، ويمكن تسميتها الDomain Modeling، وامتداد هذه الفكرة هو استخدام نموذج واحد في التحليل والتصميم وتطبيق هذا النموذج في التنفيذ (الكود)، وهذه الفكرة تسمى Model-Driven Design.
ولإيجاد هذه النموذج الموحد، وجدت الحاجة لإيجاد لغة موحدة في التواصل بين المطورين والمحللين والمتخصصين في المجال (Domain Experts) وكل ذوي العلاقة بالمشروع، وهذه اللغة تستخدم كذلك في جميع الوثائق المتعلقة بالمشروع وفي الكود والشاشات وفي كل مكان ذي صلة بالمشروع، وهذه يمكن تسميتها Ubiquitous Language (وتنطق هكذا يوبيك-وي-طاص). وهذه في الفكرة الثانية في الـ Domain-Driven Design.
الفكرة الثالثة هي التدرج والتواصل المستمر بين كل ذوي العلاقة بالمشروع لفهم مجال العمل وتحسين نموذج البرنامج وعمليات التصميم والتطوير.
هذه هي الأفكار الرئيسية في الجزء الأول من الكتاب، ومنها انبثقت بقية أفكاره.
في الجزء الثاني من الكتاب توسع المؤلف في الModel-Driven Design، فتحدث عن فكرة فصل أو عزل نموذج مجال العمال (Business Domain) ثم استعرض أنماط التصميم (Design Patterns) ذات الصلة مثل الEntities و الValue Objects وال Aggregates و ال Repositories وغيرها، وهذه الأنماط مشهورة وشائعة في أدبيات الDomain-Driven Design، حتى يظن كثير من الناس أن أنماط التصميم هذه هي ال Domain-Driven Design، وهذا من الأغلاط الشائعة، في حين أن كل الحديث عنها لم يتجاوز ثلاثة فصول من الكتاب من أصل 17 فصلا! من الأغلاط الشائعة أيضا الاعتقاد أن الDomain-Driven Design لا تطبق إلا عن طريق ال Object Oriented Programming/Design - كما قد توحي أنماط التصميم هذه، وهذا خطأ أيضا، فأي طريقة تؤدي إلى إيجاد نموذج موحد يمكن تطبيقه برمجيا جاز استعماله، ومن هذه النماذج: الWorkflow أو الـ Rule Engines، ومؤخرا صار التنفيذ باستخدام الfunctional paradigms شائعا أيضا.
الجزء الثالث من الكتاب هو الذي استمتعت به أكثر شيء، ويتكلم عن ضرورة فهم مجال العمل ووسائل تحقيق هذا الفهم، وأهمها التدرج والتحسين أو إعادة البناء المستمر (continuous refactoring)، ولا يُكتفي بذلك في الكود فقط، بل في نموذج مجال العمل أيضا (model refactoring)، إضافة إلى مبادئ نافعة في تصميم البرمجيات.
وفي الجزء الرابع والأخير، يتكلم الكتاب عن مبادئ التعامل مع مجالات العمل الضخمة، بالغة التعقيد، والتي تتطلب تكامل بين أنظمة وفرق مختلفة. ولا يُذكر التكامل إلا و يذكر معه تقاطع التقنية مع السياسة! ومن الأفكار التي وردت في هذا القسم: تقسيم مجال العمل إلى مجالات أساسية (Core Subdomain) ومجالات فرعية، وتطبيق ذلك على الBounded Contexts أو مجال تطبيق اللغة المشتركة المذكورة آنفا، وال Context Maps أي العلاقة بين الBounded Contexts المختلفة، وما يتفرع عن هذه الأفكار - وهو كثير، حيث يستغرق هذا الجزء وحده أكثر من ثلث الكتاب! -، وكذلك الكلام على التدرج في المعمارية (Evolutionary Architecture) - وإن لم ترد بهذا الاسم في الكتاب -
.
ملاحظات عامة على الكتاب
------------
المؤلف يحكي الكثير من التجارب الشخصية الناجحة والفاشلة وهذا يعطي مصداقية لكلامه.
الكتاب يبدأ بالتفاصيل ثم يتدرج للصورة الكلية (bottom-up) لكن أهمية الأفكار في الكتاب - من وجهة نظري -هي بعكس هذا الترتيب.
الكتاب دسم جدا ومليء بالأفكار الملهمة، ولذلك لا يصلح للمبتدئين، وعلى الرغم من ذكره بعض الأمثلة التطبيقية لكنها لا تكفي لتمكينك من تطبيق كل هذه الافكار بنفسك.
.
اقتباسات من الكتاب
----------
Manufacturing is a popular metaphor for software development. One inference from this metaphor: highly skilled engineers design; less skilled laborers assemble the products. This metaphor has messed up a lot of projects for one simple reason—software development is all design. All teams have specialized roles for members, but over-separation of responsibility for analysis, modeling, design, and programming interferes with MODEL-DRIVEN DESIGN.
December 29, 2012
See elsewhere for my more detailed summary.
The short summary is that Domain-Driven Design is a great book for any programmer or software designer who wants to deepen their ability to model application domains. Evans describes why domain modelling is important and sets out a number of patterns for achieving better models. He has a good grasp of real world complexities and, because of that, insists that a model must be implementable if it is to be successful. Any overlap between the model and the implementation should be identical or the model will become obsolete.
Evans provides a number of patterns to help determine the best domain model for an application. These patterns range from the abstract to the concrete, from the brilliant to the pedantic. Overall, I highly enjoyed the book although, at just over 500 pages, I am glad that I had a reading group to work through it with.
The short summary is that Domain-Driven Design is a great book for any programmer or software designer who wants to deepen their ability to model application domains. Evans describes why domain modelling is important and sets out a number of patterns for achieving better models. He has a good grasp of real world complexities and, because of that, insists that a model must be implementable if it is to be successful. Any overlap between the model and the implementation should be identical or the model will become obsolete.
Evans provides a number of patterns to help determine the best domain model for an application. These patterns range from the abstract to the concrete, from the brilliant to the pedantic. Overall, I highly enjoyed the book although, at just over 500 pages, I am glad that I had a reading group to work through it with.
November 30, 2018
I didn't like the author's style of writing/explaining.
Things were repeated and even after reading more than a hundred pages, the only thing I understood was that, developers and software architects should use domain language to discuss about the project, build diagrams and, write code. At the same time, domain experts should talk code.
Having the common language between developers and domain experts reduces the amount of errors while developing and the overall product becomes better.
The book failed to grip my attention and maybe I'll read it again in the future.
I feel that a blog article would be enough for whatever is there in the book of over 400 pages.
Things were repeated and even after reading more than a hundred pages, the only thing I understood was that, developers and software architects should use domain language to discuss about the project, build diagrams and, write code. At the same time, domain experts should talk code.
Having the common language between developers and domain experts reduces the amount of errors while developing and the overall product becomes better.
The book failed to grip my attention and maybe I'll read it again in the future.
I feel that a blog article would be enough for whatever is there in the book of over 400 pages.
February 19, 2021
Confuso e muito mal diagramado. Acho que peguei muito pouco do que ele quis passar aqui.
November 18, 2022
A must read for software engineers. There are probably a ton of better reviews than I can ever write. The initial 100~ pages are must reads. And the further you get in the book the more okay (in my opinion) it is to skip a chapter. It could probably have been two books, as the latter parts are more specific patterns and practices. I am glad i read it and even though I skipped parts of the end, I imagine I'll reread those either when specifics might be of interest (as a compendium) or when i just feel it's worth to reread, which i assume i will someday.
September 18, 2012
Been reading this on and off for a while now. I would put this on the "must read" shelf of anyone involved in the development side of software engineering, including programmers, designers, architects, even development managers. It presents a lot of important points and topics that some developers sort of know or understand but never clearly defined and put forth. There are best practices on patterns, approaches to design and development, architecture, and communication.
It takes OO development up to a new level, expanding on the generic technical ideas into the realm of domain knowledge. It's about closing the gap of understanding between business users, project owners, and and the developers.
The concepts presented take some time to absorb and are best learned when put in actual practice. It's not easy to digest but as you glean bits and pieces there, sometimes it's like, "I know doing this way always felt right", and now the book explains why it felt right. Some of the explanations are rather abstract (there are very specific examples throughout the book) for things that are hard to define, so I'd say I found it difficult to relate to things where I had no practical experience. Still, I come away from this book with a good understanding of the benefits of placing high importance on the correctness and representational value of domain model.
It takes OO development up to a new level, expanding on the generic technical ideas into the realm of domain knowledge. It's about closing the gap of understanding between business users, project owners, and and the developers.
The concepts presented take some time to absorb and are best learned when put in actual practice. It's not easy to digest but as you glean bits and pieces there, sometimes it's like, "I know doing this way always felt right", and now the book explains why it felt right. Some of the explanations are rather abstract (there are very specific examples throughout the book) for things that are hard to define, so I'd say I found it difficult to relate to things where I had no practical experience. Still, I come away from this book with a good understanding of the benefits of placing high importance on the correctness and representational value of domain model.
January 6, 2013
Excellent software engineering book. It presents a working strategy for writing and organizing software code in classes and packages in a clean and usable environment. The book presents a "common language" concept that improves communication between team members and between the team and stake holders. It presents strategies for managing code by associating class names and packages with specific functionalities, proving and common understanding of what-goes-where for a team working with domain driven design (DDD).
We have been working with DDD in our team increasingly over the last 6 months. Together with Domain-Driven Design Quickly (which we use as our quick guide) the book by Eric Evans provides excellent value for us. By helping us with create a common understanding of what different concepts, like service, model, value object etc, means to our team, we can make our code a lot better organized. By incorporating concepts from the DDD book, for example stateless services, domain objects and root aggregates we improve our code quality as well.
We have been working with DDD in our team increasingly over the last 6 months. Together with Domain-Driven Design Quickly (which we use as our quick guide) the book by Eric Evans provides excellent value for us. By helping us with create a common understanding of what different concepts, like service, model, value object etc, means to our team, we can make our code a lot better organized. By incorporating concepts from the DDD book, for example stateless services, domain objects and root aggregates we improve our code quality as well.
January 24, 2017
Check out my blog for a more detailed review and summary of the book.
This book is a must read. Although I read it from cover to cover, I think it is more useful as a reference book, going back to it to find answers for specific questions.
I think you need some practical experience (and to have faced some of the problems this book is trying to solve) in order to get the most out of it. But this doesn’t mean juniors shouldn’t read it. Actually, it contains a lot of information that I wish I would have known when I started out.
It’s clear that Eric Evans has a lot of experience in a wide range of projects. Real stories from his own experience help get the ideas across. I found the scenarios and stories really helpful. The dialogue snippets emphasize the importance of knowledge crunching. Part II contains a lot of code snippets to explain the building blocks. As the book progresses to strategic design, diagrams replace code samples. There are also extended examples that show how to use the patterns together, how they complete each other and how to apply them in real situations.
All in all, this book is timeless. I think I’ll return to it to find solutions to complex problems.
This book is a must read. Although I read it from cover to cover, I think it is more useful as a reference book, going back to it to find answers for specific questions.
I think you need some practical experience (and to have faced some of the problems this book is trying to solve) in order to get the most out of it. But this doesn’t mean juniors shouldn’t read it. Actually, it contains a lot of information that I wish I would have known when I started out.
It’s clear that Eric Evans has a lot of experience in a wide range of projects. Real stories from his own experience help get the ideas across. I found the scenarios and stories really helpful. The dialogue snippets emphasize the importance of knowledge crunching. Part II contains a lot of code snippets to explain the building blocks. As the book progresses to strategic design, diagrams replace code samples. There are also extended examples that show how to use the patterns together, how they complete each other and how to apply them in real situations.
All in all, this book is timeless. I think I’ll return to it to find solutions to complex problems.
November 27, 2019
Initially I decided not to write a review since I found a bunch of people who shared my impressions of the book and whose reviews put those impressions to words in a far more eloquent and analytical manner than I ever could but in the end it feels a shame not to say anything.
All in all, DDD was in many ways a great read, worthy of its highly lauded cult status - the ideas it presented, especially at the time of its writing, were almost groundbreaking. To top it off, the methodology it proposes seems as valid as ever so in that regard it's aged quite well (or our profession hasn't matured enough or maybe a bit of both).
Where it hasn't aged so well is the writing. At times it felt so dry and abstract and repetitive that I had to re-read whole paragraphs when the examples section came around because I've forgotten what the examples were about to demonstrate. I also quickly learned not to bother if I wasn't at the top of my game concentration-wise. While DDD is definitely a complex topic, it definitely isn't more complex than others I've read about but it certainly felt so...
So there it is, my 2¢. You'll excuse the lack of potatoes though.
All in all, DDD was in many ways a great read, worthy of its highly lauded cult status - the ideas it presented, especially at the time of its writing, were almost groundbreaking. To top it off, the methodology it proposes seems as valid as ever so in that regard it's aged quite well (or our profession hasn't matured enough or maybe a bit of both).
Where it hasn't aged so well is the writing. At times it felt so dry and abstract and repetitive that I had to re-read whole paragraphs when the examples section came around because I've forgotten what the examples were about to demonstrate. I also quickly learned not to bother if I wasn't at the top of my game concentration-wise. While DDD is definitely a complex topic, it definitely isn't more complex than others I've read about but it certainly felt so...
So there it is, my 2¢. You'll excuse the lack of potatoes though.
April 22, 2017
I am at page 125 thinking not losing any more precious time from my life with it. I wonder what is wrong with the world rating this book so high. While the problem with "Pragmatic programmer" was that it is for someone with less than 10 years experience the problem with this one is that it is just a Bla. Fascinated with design, design patterns and flexibility of development I started this book really enthusiastically and then came the bla. One line of information two pages of bla. And the information was not rocking my world either. Please do read design patterns explained, modern design, joel on Software.. Do not search deep meaning in this one.
December 16, 2018
A lot of the concepts from this book should be obvious to an experienced software developer. Despite this, it was an important read.
The book is too lengthy, so I scanned it from time to time. I also supported my reading with browsing the ideas from the book on the internet.
The book is too lengthy, so I scanned it from time to time. I also supported my reading with browsing the ideas from the book on the internet.
May 15, 2017
This book contains some interesting conceptions/terms. Like - Entity, Value Object, Closure of Operations, Repository, side effect free function, Core Domain, Bounded Context.
May 26, 2017
There is a lot of things to learn in here. Probably I should read it again.
June 19, 2017
Needs an editor
Displaying 1 - 30 of 326 reviews