Why a Domain Model?
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
Please report any problems with this page to Tres Seaver, tseaver@palladion.com.