How much do I want to read more? 7/10
Unfortunately, this book is using Java, which I learned 15 years ago, but I don't plan to work with in the future.
Still, It can apply to any programming language.
It looks like a huge investment to read and it seems to benefit complex systems most.
So I'm not sure how far I'll dig in this book.
A good domain model can be incredibly valuable, but it's not something that's easy to make. Few people can do it well, and it's very hard to teach.
Like many people, I've come to reject the phased thinking of "design, then build." But the lesson of Eric's experience is that the really powerful domain models evolve over time, and even the most experienced modelers find that they gain their best ideas after the initial releases of a system.
This book is a synthesis of widely accepted best practices along with my own insights and experiences.
The challenge of complexity
the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain complexity is not handled in the design, it won't matter that the infrastructural technology is well conceived.
Part I: Putting the Domain Model to Work
Maps are models.
A model is a simplification. It is an interpretation of reality that abstracts the aspects relevant to solving the problem at hand and ignores extraneous detail.
The Utility of a Model in Domain-Driven Design
The Heart of Software
Most talented developers do not have much interest in learning about the specific domain in which they are working.
Technical people enjoy quantifiable problems that exercise their technical skills. Domain work is messy and demands a lot of complicated new knowledge that doesn't seem to add to a computer scientist's capabilities.
Instead, the technical talent goes to work on elaborate frame-works, trying to solve domain problems with technology. Learning about and modeling the domain is left to others.
Creating a lucid model that cuts through that complexity is exciting.
Chapter One. Crunching Knowledge
Effective domain modelers are knowledge crunchers. They take a torrent of information and probe for the relevant trickle.
The interaction between team members changes as all members crunch the model together. The constant refinement of the domain model forces the developers to learn the important principles of the business they are assisting, rather than to produce functions mechanically.
When we set out to write software, we never know enough.