Domain-Driven Design Quotes

“If the implementer has state that is used in the computation, then the implementer is effectively an argument of the operation,”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“A deep model has power because it contains the central concepts and abstractions that can succinctly and flexibly express essential knowledge of the users’ activities, their problems, and their solutions.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“This tight coupling of the application to the specifics of the implementation strips away most of the benefits of abstraction in the domain layer and makes continuing changes ever more expensive.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Complex object creation is a responsibility of the domain layer, yet that task does not belong to the objects that express the model.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“The complexity of a highly detailed interaction ends up being handled in the application layer, allowing domain knowledge to creep into the application or user interface code, where it is lost from the domain layer.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“The domain model will typically derive from the domain experts’ own jargon but will have been “cleaned up,” to have sharper, narrower definitions.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Success comes in an emerging set of abstract concepts that make sense of all the detail”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Tightly relating the code to an underlying model gives the code meaning and makes the model relevant.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Simple, informal UML diagrams can anchor a discussion.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“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.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“crucial discoveries always emerge during the design/implementation effort.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“The astrolabe was a mechanical implementation of an object-oriented model of the sky.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“There is no need for explanatory models to be object models, and it is generally best if they are not.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“you may hear the UBIQUITOUS LANGUAGE changing naturally while a document is being left behind.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Written documents should complement the code and the talking.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“A document shouldn’t try to do what the code already does well.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“documenting exclusively through code has some of the same basic problems as using comprehensive UML diagrams.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“The behavior of running code is unambiguous.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“the model is not the diagram.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software