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

Architectural Frameworks
When infrastructure is provided in the form of 
SERVICES
called on through interfaces, it is fairly
intuitive how the layering works and how to keep the layers loosely coupled. But some technical
problems call for more intrusive forms of infrastructure. Frameworks that integrate many
infrastructure needs often require the other layers to be implemented in very particular ways, for
example as a subclass of a framework class or with structured method signatures. (It may seem
counterintuitive for a subclass to be in a layer higher than that of the parent class, but keep in
mind which class reflects more knowledge of the other.) The best architectural frameworks solve
complex technical problems while allowing the domain developer to concentrate on expressing a
model. But frameworks can easily get in the way, either by making too many assumptions that
constrain domain design choices or by making the implementation so heavyweight that
development slows down.
Some form of architectural framework usually is needed (though sometimes teams choose
frameworks that don't serve them well). When applying a framework, the team needs to focus on
its goal: building an implementation that expresses a domain model and uses it to solve important
problems. The team must seek ways of employing the framework to those ends, even if it means
not using all of the framework's features. For example, early J2EE applications often implemented
all domain objects as "entity beans." This approach bogged down both performance and the pace
of development. Instead, current best practice is to use the J2EE framework for larger grain
objects, implementing most business logic with generic Java objects. A lot of the downside of
frameworks can be avoided by applying them selectively to solve difficult problems without looking
for a one-size-fits-all solution. Judiciously applying only the most valuable of framework features
reduces the coupling of the implementation and the framework, allowing more flexibility in later
design decisions. More important, given how very complicated many of the current frameworks are
to use, this minimalism helps keep the business objects readable and expressive.
Architectural frameworks and other tools will continue to evolve. Newer frameworks will automate
or prefabricate more and more of the technical aspects of an application. If this is done right,
application developers will increasingly concentrate their time on modeling the core business
problems, greatly improving productivity and quality. But as we move in this direction, we must
guard against our enthusiasm for technical solutions; elaborate frameworks can also straitjacket
application developers.
[ Team LiB ]

---

[ Team LiB ]