Domain-Driven Design: Tackling Complexity in the Heart of Software

The Domain Layer Is Where the Model Lives
L
AYERED ARCHITECTURE
is used in most systems today, under various layering schemes. Many styles
of development can also benefit from layering. However, domain-driven design requires only one
particular layer to exist.
The domain model is a set of concepts. The "domain layer" is the manifestation of that model and
all directly related design elements. The design and implementation of business logic constitute the
domain layer. In a 
MODEL-DRIVEN DESIGN
, the software constructs of the domain layer mirror the
model concepts.
It is not practical to achieve that correspondence when the domain logic is mixed with other
concerns of the program. Isolating the domain implementation is a prerequisite for domain-driven
design.
[ Team LiB ]

---

[ Team LiB ]
The Smart UI "Anti-Pattern"
. . . That sums up the widely accepted 
LAYERED ARCHITECTURE
pattern for object applications. But
this separation of UI, application, and domain is so often attempted and so seldom accomplished
that its negation deserves a discussion in its own right.
Many software projects do take and should continue to take a much less sophisticated design
approach that I call the 
SMART
UI. But 
SMART
UI is an alternate, mutually exclusive fork in the road,
incompatible with the approach of domain-driven design. If that road is taken, most of what is in
this book is not applicable. My interest is in the situations where the 
SMART
UI does not apply,
which is why I call it, with tongue in cheek, an "anti-pattern." Discussing it here provides a useful
contrast and will help clarify the circumstances that justify the more difficult path taken in the rest
of the book.
A project needs to deliver simple functionality, dominated by data entry and display, with few
business rules. Staff is not composed of advanced object modelers.