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

particular UI.
Disadvantages
Integration of applications is difficult except through the database.
There is no reuse of behavior and no abstraction of the business problem. Business rules
have to be duplicated in each operation to which they apply.
Rapid prototyping and iteration reach a natural limit because the lack of abstraction limits
refactoring options.
Complexity buries you quickly, so the growth path is strictly toward additional simple
applications. There is no graceful path to richer behavior.
If this pattern is applied consciously, a team can avoid taking on a great deal of overhead required
by other approaches. It is a common mistake to undertake a sophisticated design approach that
the team isn't committed to carrying all the way through. Another common, costly mistake is to
build a complex infrastructure and use industrial-strength tools for a project that doesn't need
them.
Most flexible languages (such as Java) are overkill for these applications and will cost dearly. A
4GL-style tool is the way to go.
Remember, one of the consequences of this pattern is that you can't migrate to another design
approach except by replacing entire applications. Just using a general-purpose language such as
Java won't really put you in a position to later abandon the 
SMART
UI, so if you've chosen that
path, you should choose development tools geared to it. Don't bother hedging your bet. Just using
a flexible language doesn't create a flexible system, but it may well produce an expensive one.
By the same token, a team committed to a 
MODEL-DRIVEN DESIGN
needs to design that way from
the outset. Of course, even experienced project teams with big ambitions have to start with simple
functionality and work their way up through successive iterations. But those first tentative steps
will be 
MODEL-DRIVEN
with an isolated domain layer, or the project will most likely be stuck with a

---

SMART
UI. The 
SMART
UI is discussed only to clarify why and when a pattern such as 
LAYERED
ARCHITECTURE
is needed in order to isolate a domain layer.
There are other solutions in between 
SMART
UI and 
LAYERED ARCHITECTURE
. For example, Fowler
(2002) describes the 
TRANSACTION SCRIPT
, which separates UI from application but does not
provide for an object model. The bottom line is this: 
If the architecture isolates the domain-related
code in a way that allows a cohesive domain design loosely coupled to the rest of the system, then
that architecture can probably support domain-driven design.
Other development styles have their place, but you must accept varying limits on complexity and
flexibility. Failing to decouple the domain design can really be disastrous in certain settings. If you
have a complex application and are committing to 
MODEL-DRIVEN DESIGN
, bite the bullet, get the
necessary experts, and 
avoid
the 
SMART
UI.
[ Team LiB ]

---

[ Team LiB ]