Domain-Driven Design Quotes

Rate this book
Clear rating
Domain-Driven Design: Tackling Complexity in the Heart of Software Domain-Driven Design: Tackling Complexity in the Heart of Software by Eric Evans
3,422 ratings, 4.14 average rating, 152 reviews
Open Preview
Domain-Driven Design Quotes Showing 1-30 of 40
“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
“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.”
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
“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
“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
“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
“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
“Every software program relates to some activity or interest of its user.”
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
“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.”
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
“Knowledge trickles in one direction, but does not accumulate.”
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
“That shallowness of knowledge produces software that does a basic job but lacks a deep connection to the domain expert’s way of thinking.”
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
“Diagrams are a means of communication and explanation, and they facilitate brainstorming. They serve these ends best if they are minimal.”
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
“the model is not the diagram.”
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
“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
“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
“Written documents should complement the code and the talking.”
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
“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
“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
“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
“crucial discoveries always emerge during the design/implementation effort.”
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
“The heart of software is its ability to solve domain-related problems for its user. All other features, vital though they may be, support this basic purpose. When the domain is complex, this is a difficult task, calling for the concentrated effort of talented and skilled people. Developers have to steep themselves in the domain to build up knowledge of the business. They must hone their modeling skills and master domain design. Yet these are not the priorities on most software projects. 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. Domain work is messy and demands a lot of complicated new knowledge that doesn’t seem to add to a computer scientist’s capabilities. Instead, the technical talent goes to work on elaborate frameworks, trying to solve domain problems with technology. Learning about and modeling the domain is left to others. Complexity in the heart of software has to be tackled head-on. To do otherwise is to risk irrelevance.”
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
“When we set out to write software, we never know enough.”
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software
“The domain experts had learned more and had clarified the goal of the application.”
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

« previous 1