Eric Evans > Quotes

“The heart of software is its ability to solve domain-related problems for its user.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“A model is a selectively simplified and consciously structured form of knowledge.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“It takes fastidiousness to write code that doesn’t just do the right thing but also says the right thing.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

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

“there should be some learning when a domain model is discussed.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

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

“Knowledge crunching is an exploration, and you can’t know where you will end up.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“The vital detail about the design is captured in the code. A well-written implementation should be transparent, revealing the model underlying it.”
― 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 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

“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

“Every software program relates to some activity or interest of its user.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“They show design constraints, but they are not design specifications in every detail. They represent the skeletons of ideas.”
― 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

“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

“An AGGREGATE is a cluster of associated objects that we treat as a unit for the purpose of data changes.”
― 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

“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

“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

“By using the model-based language pervasively and not being satisfied until it flows, we approach a model that is complete and comprehensible, made up of simple elements that combine to express complex ideas.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

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

“Software design is a constant battle with complexity. We must make distinctions so that special handling is applied only where necessary.”
― 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

“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

“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

“The kind of knowledge captured in a model such as the PCB example goes beyond “find the nouns.”
― 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

“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

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

“When we set out to write software, we never know enough.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software