Domain-Driven Design

Problem—The Analysis-Design Gap

The goal of the analysis model is to faithfully represent the application domain. This can be useful to help understand the ideas behind the use cases.

The analysis model can also be useful for defining the domain layer of a layered architecture.

Recall the layered architecture:

 

 

But the goal of the design model is implementation. Over time this difference in goals can lead to a gap between the analysis and design models. The analysis model becomes a museum piece (or worse, a source of confusion) as mounting implementation concerns widen the analysis-design gap. Meanwhile, the design model moves further away from important domain concepts, relationships, and language.

The Solution: Domain-Driven Design (DDD)

Make the domain model the domain layer of the design model.

Ambiguity and awkwardness in the domain layer are interpreted as subtleties missing from the domain model rather than excuses for obscure code hacks.

The domain model/layer is produced in iterations, with the focus of early iterations on capturing domain concepts and later iterations focused on implementation issues, but without grossly violating the faithfulness of the model.

The domain also contains algorithms, implicit and explicit, so implementation can be mixed in with analysis and design.

DDD Patterns

DDD can be viewed as a pair of pattern languages. The Problem Space Patterns are used in the early iterations that focus on domain modeling, while the Solution Space Patterns focus on the later iterations where implementation issues are a focus. Many DDD Patterns can be found in my Analysis Patterns Catalog.

DDD Labs

DDD Labs

References

Domain-Driven Design, Tackling Complexity in the Heart of Software; Eric Evans; Addison-Wesley; 2004.

http://dddcommunity.org/

Patterns, Principles, and Practices of Domain-Driven Design; Scott Millett with Nick Tune; Wrox; 2013.