Find & Share Quotes with Friends

Sign in
options

Join Goodreads

Error rating book. Refresh and try again.

Rate this book

Clear rating

“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

“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

“A model is a selectively simplified and consciously structured form of knowledge.”
― 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

“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

“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

“there should be some learning when a domain model is discussed.”
― 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

“One other case that drives people to combine FACTORY and REPOSITORY is the desire for “find or create” functionality, in which a client can describe an object it wants and, if no such object is found, will be given a newly created one. This function should be avoided. It is a minor convenience at best. A lot of cases in which it seems useful go away when ENTITIES and VALUE OBJECTS are distinguished. A client that wants a VALUE OBJECT can go straight to a FACTORY and ask for a new one. Usually, the distinction between a new object and an existing object is important in the domain, and a framework that transparently combines them will actually muddle the situation.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Although the REPOSITORY will insert into and delete from the database, it will ordinarily not commit anything. It is tempting to commit after saving, for example, but the client presumably has the context to correctly initiate and commit units of work. Transaction management will be simpler if the REPOSITORY keeps its hands off.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“these ad hoc solutions divert attention away from the model, and soon you are back to hacking and hoping.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“If the available tool does not facilitate that expressiveness, reconsider the choice of tools. An unexpressive implementation negates the advantage of the extra paradigm.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Unless there is a real intention to distribute code on different servers, keep all the code that implements a single conceptual object in the same MODULE, if not the same object.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“fine-grained objects can lead to inefficient messaging in a distributed system.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“A good SERVICE has three characteristics. 1. The operation relates to a domain concept that is not a natural part of an ENTITY or VALUE OBJECT. 2. The interface is defined in terms of other elements of the domain model. 3. The operation is stateless.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Try to completely eliminate bidirectional associations between VALUE OBJECTS. If in the end such associations seem necessary in your model, rethink the decision to declare the object a VALUE OBJECT in the first place. Maybe it has an identity that hasn’t been explicitly recognized yet.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Isolating the domain implementation is a prerequisite for domain-driven design.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“frameworks can easily get in the way, either by making too many assumptions that constrain domain design choices or by making the implementation so heavyweight that development slows”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“all approaches are fine as long as they maintain the isolation of the domain layer, allowing domain objects to be designed without simultaneously thinking about the user interface that might interact with them.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Developing a good domain model is an art. But the practical design and implementation of a model’s individual elements can be relatively systematic.”
― Evans Eric, 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.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Across this linguistic divide, the domain experts vaguely describe what they want. Developers, struggling to understand a domain new to them, vaguely understand. A few members of the team manage to become bilingual, but they become bottlenecks of information flow, and their translations are inexact.”
― Evans Eric, Domain-Driven Design: Tackling Complexity in the Heart of Software

“Extreme Programming concentrates exclusively on the active elements of a program and executable tests. Even comments added to the code do not affect program behavior, so they always fall out of sync with the active code and its driving model. External documents and diagrams do not affect the behavior of the program, so they fall out of sync. On the other hand, spoken communication and ephemeral diagrams on whiteboards do not linger to create confusion. This dependence on the code as communication medium motivates developers to keep the code clean and transparent.”
― Evans Eric, 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

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

“Extreme Programming recognizes the importance of design decisions, but it strongly resists upfront design. Instead, it puts an admirable effort into communication and improving the project’s ability to change course rapidly. With that ability to react, developers can use the “simplest thing that could work” at any stage of a project and then continuously refactor, making many small design improvements, ultimately arriving at a design that fits the customer’s true needs.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software

“The goal is that not only can a developer understand what the code does; he or she can also understand why it does what it does and can relate that to the ongoing communication with the domain experts.”
― 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

“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

“Supple design has a profound effect on the ability of software to cope with change and complexity.”
― Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software