Why a Domain Model?
Limitations of RAD
Advantages of Domain Modeling
Tradeoffs
Limitations of RAD
RAD suffers from the "strenghts of its weaknesses" syndrome:
the very features which make it easy to throw together a workable application
(auto-generated component noise names, all application logic as form-level
methods, etc.), also work to impede the scalability and maintainability
of the application, and its fidelity to the domain model.
Scalability
Because code in a RAD'ed application is highly centralized (which makes
for "easy" initial development), reusing useful pieces of application
logic across multiple forms and applications can require "bend over
backwards" compromises in the originating form's design.
Maintainability
Adding new variations of behavior to these "monolithic" repositories
often requires making multiple changes to the form, thus creating numerous
opportunites for introducing bugs into the working code.
Fidelity to Application Domain Logic
As applications (and their functionality) grow, the effort required to
keep multiple forms and applications in synch with the often rapid changes
to the business logic which they support. This limitation heterodynes with
the first two, leading some to spell out RAD as "rapid application
death" -- it rapidly becomes cheaper to throw out the recently completed
version and code afresh, rather than attempt to maintain the deployed version.
Return
to top
Advantages of Domain Modeling
Partitioning
Domain object models come to the fore as applications grow beyond the scope
of the heroic model of programming we all know and love. They yield their
greatest benefits when they allow a system's designer to carve up the application
along natural lines. Such a a "divide and conquer" strategy provides
almost the only feasible approach to managing that complexity (as long
since noted by Fred Brooks in his seminal essay,
The Mythical Man Month).
Scalability
As applications grow in size and complexity, only Because they support
and utilize the inherent structure of the users work patterns, diivisions
which follow the "cleavage lines" of the problem domain give
the most leverage to the partitioning effort. Domain models allows the
design team to identify these "perforations" in the problem space,
maximizing the cohesiveness of the domain-centered modules of the system
while simultaneously reducing their coupling to unrelated parts.
Maintainability
Because unrelated portions of the system remain only loosely coupled when
the system is divided along domain-driven lines, the potential for introducing
new bugs during "minor;" maintenance is much reduced. Likewise,
constructing the application on the foundation provided by the domain model
allows for enhancements which work within, rather than against, the application's
structure.
Fidelity
What we once called "requirements creep" is fast becoming "requirements
blur," as users' expectations for the usefulness and usability of
software grows, seemingly without bound. The roadmap which a good domain
model provides gives the developer at least some hope of keeping up with
these demands, and even of anticipating them.
Return
to top
Tradeoffs
While the effort to build a domain object model is certainly not insiginificant,
the payoffs can be enormous. Everyone can relate stories about "quick
fix" projects which mushroomed into maintenance nightmares. Planning
for growth gives a project at least a reasonable chance of coming out on
top of the software entropy curve.
Return
to top
TOC
| Next
Copyright 1997, Palladion
Software.
Please report any problems with this page to Tres
Seaver, tseaver@palladion.com.
