Quotes from Eric Evans

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

A model is a selectively simplified and consciously structured form of knowledge.

It takes fastidiousness to write code that doesn't just do the right thing but also says the right thing.

To communicate effectively, the code must be based on the same language used to write the requirements—the same language that the developers speak with each other and with domain experts.

The vital detail about the design is captured in the code. A well-written implementation should be transparent, revealing the model underlying it.

there should be some learning when a domain model is discussed.

Knowledge crunching is an exploration, and you can't know where you will end up.

Listen to the language the domain experts use. Are there terms that succinctly state something complicated? Are they correcting your word choice (perhaps diplomatically)? Do the puzzled looks on their faces go away when you use a particular phrase? These are hints of a concept that might benefit the model.

Software design is a constant battle with complexity. We must make distinctions so that special handling is applied only where necessary.

There are at least three ways of making associations more tractable. 1. Imposing a traversal direction 2. Adding a qualifier, effectively reducing multiplicity 3. Eliminating nonessential associations

But, while bidirectional associations between ENTITIES may be hard to maintain, bidirectional associations between two VALUE OBJECTS just make no sense. Without identity, it is meaningless to say that an object points back to the same VALUE OBJECT that points to it. The most you could say is that it points to an object that is equal to the one pointing to it, but you would have to enforce that invariant somewhere.

When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as a standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LAN- GUAGE. Make the SERVICE stateless.

Every software program relates to some activity or interest of its user.

Success comes in an emerging set of abstract concepts that makes sense of all the detail. This distillation is a rigorous expression of the particular knowledge that has been found most relevant.

Yet it is a legitimate pattern in some other contexts. In truth, there are advantages to the SMART UI, and there are situations where it works best—which partially accounts for why it is so common.

In the old waterfall method, the business experts talk to the analysts, and analysts digest and abstract and pass the result along to the programmers, who code the software. This approach fails because it completely lacks feedback.

Knowledge trickles in one direction, but does not accumulate.

That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the domain expert's way of thinking.

Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal.

All public elements of a design together make up its interface, and the name of each of those elements presents an opportunity to reveal the intention of the design.

They show design constraints, but they are not design specifications in every detail. They represent the skeletons of ideas.

the model is not the diagram.

The behavior of running code is unambiguous.

documenting exclusively through code has some of the same basic problems as using comprehensive UML diagrams.