Quotes from Eric Evans

A document shouldn't try to do what the code already does well.

Written documents should complement the code and the talking.

you may hear the UBIQUITOUS LANGUAGE changing naturally while a document is being left behind.

There is no need for explanatory models to be object models, and it is generally best if they are not.

In general, don't fight your frameworks. Seek ways to keep the fundamentals of domain-driven design and let go of the specifics when the framework is antagonistic.

The astrolabe was a mechanical implementation of an object-oriented model of the sky.

Factoring the constraint into its own method allows us to give it an intention-revealing name that makes the constraint explicit in our design. It is now a named thing we can discuss.

crucial discoveries always emerge during the design/implementation effort.

If the design, or some central part of it, does not map to the domain model, that model is of little value, and the correctness of the software is suspect.

The domain model will typically derive from the domain experts' own jargon but will have been "cleaned up," to have sharper, narrower definitions.

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.

Supple design has a profound effect on the ability of software to cope with change and complexity.

Whatever the cause, software that lacks a concept at the foundation of its design is, at best, a mechanism that does useful things without explaining its actions.

An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.

If developers don't realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it.

Persistent use of the UBIQUITOUS LANGUAGE will force the model's weaknesses into the open. The team will experiment and find alternatives to awkward terms or combinations. As gaps are found in the language, new words will enter the discussion. These changes to the language will be recognized as changes in the domain model and will lead the team to update class diagrams and rename classes and methods in the code, or even change behavior, when the meaning of a term changes.

When we set out to write software, we never know enough.

The domain experts had learned more and had clarified the goal of the application.

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. Technical people enjoy quantifiable problems that exercise their technical skills.

Simple, informal UML diagrams can anchor a discussion.

Any technical person contributing to the model must spend some time touching the code, whatever primary role he or she plays on the project. Anyone responsible for changing code must learn to express a model through the code. Every developer must be involved in some level of discussion about the model and have contact with domain experts. Those who contribute in different ways must consciously engage those who touch the code in a dynamic exchange of model ideas through the UBIQUITOUS LANGUAGE

Because the domain experts are feeding into it, it reflects deep knowledge of the business and those abstractions are true business principles.

Success comes in an emerging set of abstract concepts that make sense of all the detail

Business activities and rules are as central to a domain as are the entities involved; any domain will have various categories of concepts.