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

Access to S
ERVICES
Distributed system architectures, such as J2EE and CORBA, provide special publishing mechanisms
for 
SERVICES
, with conventions for their use, and they add distribution and access capabilities. But
such frameworks are not always in use on a project, and even when they are, they are likely to be
overkill when the motivation is just a logical separation of concerns.
The means of providing access to a 
SERVICE
is not as important as the design decision to carve off
specific responsibilities. A "doer" object may be satisfactory as an implementation of a 
SERVICE
's
interface. A simple 
SINGLETON
(Gamma et al. 1995) can be written easily to provide access. Coding
conventions can make it clear that these objects are just delivery mechanisms for 
SERVICE
interfaces, and not meaningful domain objects. Elaborate architectures should be used only when
there is a real need to distribute the system or otherwise draw on the framework's capabilities.
[ Team LiB ]

---

[ Team LiB ]
Modules (a.k.a. Packages)
M
ODULES
are an old, established design element. There are technical considerations, but cognitive
overload is the primary motivation for modularity. M
ODULES
give people two views of the model:
They can look at detail within a 
MODULE
without being overwhelmed by the whole, or they can look
at relationships between 
MODULES
in views that exclude interior detail.
The 
MODULES
in the domain layer should emerge as a meaningful part of the model, telling the
story of the domain on a larger scale.
Everyone uses 
MODULES
, but few treat them as a full-fledged part of the model. Code
gets broken down into all sorts of categories, from aspects of the technical architecture