Domain-Driven Design

Pattern Summaries

Excerpted from Domain-Driven Design: Tackling Complexity in the Heart of Software, by Eric Evans, Addison-Wesley 2004.

This document is distributed under the Creative Commons Deed: Attribution 2.0.

You are free: ← to copy, distribute, display, and perform the work ← to make derivative works ← to make commercial use of the work

Under the following conditions: Attribution You must give the original author credit with the following attribution: Eric Evans, DOMAIN-DRIVEN DESIGN, Addison-Wesley, ( Eric Evans, 2004.

For any reuse or distribution, you must make clear to others the license terms of this work.

Any of these conditions can be waived if you …ver más…

Draw from the model the terminology used in the design and the basic assignment of responsibilities. The code becomes an expression of the model, so a change to the code may be a change to the model. Its effect must ripple through the rest of the project’s activities accordingly.
To tie the implementation slavishly to a model usually requires software development tools and languages that support a modeling paradigm, such as object-oriented programming.

Hands-On Modelers

If the people who write the code do not feel responsible for the model, or don’t understand how to make the model work for an application, then the model has nothing to do with the software. If developers don’t realize that changing code changes the model, then their refactoring will weaken the model rather than strengthen it. Meanwhile, when a modeler is separated from the implementation process, he or she never acquires, or quickly loses, a feel for the constraints of implementation. The basic constraint of model-driven design—that the model supports an effective implementation and abstracts key insights into the domain—is half-gone, and the resulting models will be impractical. Finally, the knowledge and skills of experienced designers won’t be transferred to other developers if the division of labor prevents the kind of collaboration that conveys the subtleties of coding a model-driven design.

Therefore,

Any