Domain driven design

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 thework

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 get permission from the copyright holder.

Forthe full text of the license, see the following web sites:

http://creativecommons.org/licenses/by/2.0/
http://creativecommons.org/licenses/by/2.0/legalcode

Part I

Putting the Model To Work

Ubiquitous Language

To create a supple, knowledge-rich design calls for a versatile, shared team language, and a lively experimentation with language that seldom happens on software projects.A project faces serious problems when its language is fractured. Domain experts use their jargon while technical team members have their own language tuned for discussing the domain in terms of design.
The terminology of day-to-day discussions is disconnected from the terminology embedded in the code (ultimately the most important product of a software project). And even the same person usesdifferent language in speech and in writing, so that the most incisive expressions of the domain often emerge in a transient form that is never captured in the code or even in writing.
Translation blunts communication and makes knowledge crunching anemic.
Yet none of these dialects can be a common language because none serves all needs.

Therefore:

Use the model as the backbone of alanguage. Commit the team to exercising that language relentlessly in all communication within the team and in the code. Use the same language in diagrams, writing, and especially speech.
Iron out difficulties by experimenting with alternative expressions, which reflect alternative models. Then refactor the code, renaming classes, methods, and modules to conform to the new model. Resolve confusion overterms in conversation, in just the way we come to agree on the meaning of ordinary words.
Recognize that a change in the language is a change to the model.
Domain experts should object to terms or structures that are awkward or inadequate to convey domain understanding; developers should watch for ambiguity or inconsistency that will trip up design.
With a ubiquitous language, the model is notjust a design artifact. It becomes integral to everything the developers and domain experts do together.

Also,

Play with the model as you talk about the system. Describe scenarios out loud using the elements and interactions of the model, combining concepts in ways allowed by the model. Find easier ways to say what you need to say, and then take those new ideas back down to the diagrams andcode.

Model-Driven Design

Tightly relating the code to an underlying model gives the code meaning and makes the model relevant.

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. At the same time, complex mappings between models and design functions are difficult to understand and, inpractice, impossible to maintain as the design changes. A deadly divide opens between analysis and design so that insight gained in each of those activities does not feed into the other.

Therefore,

Design a portion of the software system to reflect the domain model in a very literal way, so that mapping is obvious. Revisit the model and modify it to be implemented more naturally in...