Domain Driven Design Cover

Domain-Driven Design - by Eric Evans

ISBN-13: 978-0321125217

Go to the Amazon page for details and reviews.

"Domain-Driven Design" by Eric Evans is a clever deep-dive into software complexity. It links domain experts and developers with a unique methodology. The book is full of innovative ideas for aligning software with business needs. Reading it feels like unlocking new insights into software design, growing more compelling with each read. A concise, insightful journey.

MY NOTES

When complexity gets out of hand, developers can no longer understand the software well enough to change or extend it easily and safely.

For most software projects, the primary focus should be on the domain and domain logic.

Complex domain designs should be based on a model.

Domain-driven design is both a way of thinking and a set of priorities, aimed at accelerating software projects that have to deal with complicated domains.

A good design can create opportunities to exploit those complex features.

Yet the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user.

Design concepts must be implemented successfully or else they will dry up into academic discussion.

Developers and domain experts have a close relationship. Domain-driven design crunches a huge amount of knowledge into a model that reflects deep insight into the domain and a focus on the key concepts.

Extreme Programming recognizes the importance of design decisions, but it strongly resists upfront design.

Continuous refactoring is a series of small redesigns; developers without solid design principles will produce a code base that is hard to understand or change—the opposite of agility.

The model and the heart of the design shape each other.

It is the intimate link between the model and the implementation that makes the model relevant and ensures that the analysis that went into it applies to the final product, a running program.

The model is the backbone of a language used by all team members.

The model is distilled knowledge.

Using a model in these ways can support the development of software with rich functionality that would otherwise take a massive investment of ad hoc development.

The heart of software is its ability to solve domain-related problems for its user.

When the domain is complex, this is a difficult task, calling for the concentrated effort of talented and skilled people.

Most talented developers do not have much interest in learning about the specific domain in which they are working, much less making a major commitment to expand their domain-modeling skills.

Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.

Learning about and modeling the domain is left to others, while the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology.

The messiness of most software domains is actually an interesting technical challenge.

There are systematic ways of thinking that developers can employ to search for insight and produce effective models.

It is the creativity of brainstorming and massive experimentation, leveraged through a model-based language and disciplined by the feedback loop through implementation, that makes it possible to find a knowledge-rich model and distill it. This kind of knowledge crunching turns the knowledge of the team into valuable models.

Effective domain modelers are knowledge crunchers.

Knowledge crunching is not a solitary activity. A team of developers and domain experts collaborate, typically led by developers.

Other projects use an iterative process, but they fail to build up knowledge because they don't abstract.