Domain Driven Design

Description

XPers are often suspicious of modeling and design processes, and with some justification. One problem is that modeling is often viewed as an "up-front" activity. The deepest insight of any project is available at the end, not the beginning, so up-front modeling saddles the project with the most ignorant view of the domain that the team will ever have. Another problem is that modeling has been undertaken as a separate "analysis" activity, divorced from programming. Analysis models become irrelevant to the software, and such processes separate the programmers from the domain experts.

Rejecting all that, XP teams strive to improve communication among all team members, including programmers and domain experts. The currency of that communication is a shared set of concepts and their interactions: a model, in short.

The premise of domain-driven design is that development of complex software applications should revolve around an evolving domain model and that most activities should become modeling activities -- including programming.

This calls for an broadened view of refactoring. Refactoring is fundamental to XP. It is the key to the freedom to change, but it also depends on practices that enable easy change. There is now extensive literature on the mechanics of changing code and the common detailed transformations, yet the refactorings with the biggest impact on the viability of a system are those motivated by new insights into the domain or those that bring out the domain model more clearly in the code. This refactoring toward deeper insight, along with certain kinds of model choices, makes the design more supple -- inviting to change and use in new ways.

The marriage of XP and DDD allows a team to exploit its continually improving understanding of the domain to produce more valuable software that stays open to change. --EricEvans

XP projects have two user interfaces - the production one and the StoryTest? one. The latter forms a view of the raw data and manipulations under the hood. So applying a SystemMetaphor? to this view turns it into a model - abstracted from the real programmers' model, but integrated with the system's domain abstractions. --PhlIp