I've had discussions with many developers who develop Object-Oriented (OO) programs and, often, I'm surprised by the areas of concern to them.
Often, discussions center around the choice of a controller (such as Model-Glue, Mach-II, or Fusebox), followed by supporting frameworks (ColdSpring, Transfer, Reactor)--and that's it.
Missing from these discussions is what I consider to be the most important topic of any discussion about software applications--the domain model. I've wondered about this, as it seems so key that I can't fathom how the domain model could get such short shrift.
What is a "domain model"? To answer this, we need to define the term, "domain". At its most basic level, a domain is the aspect of realty that is of interest to the user. If we're working on building a stock trading application, the domain is the world of Wall Street. If we're building an employee management system, Human Relations (HR) is the domain.
The "model' in domain model is the simplification of a domain for purposes of capturing it in software. If you substitute the term, "map", for domain, it may give you a better way to think of a model. In the same way that a map is a simplification of its domain (geography), a software model captures the essence of the pertinent domain (finance, HR, etc.).
And just as there are different types of maps (population maps, climate maps, political maps), the requirements for
a particular application will shape the model. But, however abstracted (simplified) and idealized domain models may be, if they are to be useful, they must conform to the reality of the underlying domain.
In my discussions with other developers, where they discuss domain models at all, they focus on the entities involved and the data associated with them. So, in my hypothetical stock trading application, they would doubtless identify a domain component called "Stock" and "model" it something like this:
- tickerSymbol: string
- stockName: string
- currentPrice: numeric
- exchange: Exchange
- history: History
...and so on. Perhaps the deeper thinkers in the group may realize that a Stock is really a special case of a Security object. All stocks are securities, but not all securities are stocks--as, for instance, bonds, warrants, options, and futures.
That surely seems to meet the requirements for inheritance, so our "domain modelers" may note that Stock extends Security and they may even move some of the data from Stock to Security. Give them a couple of days and they'll have their "model" finished.
What's missing from this model? Behavior. And behavior is what differentiates similar entities from one organization to the next.
Domain models that lack behavior are sometimes called anemic. They are little more than a way to aggregate data -- a useful enough practice, but by no means sufficient for building rich, OO applications. It's not as if we're not warned against the dangers of anemic domain models; OO design books are full of admonitions against them. Yet, for many -- perhaps most -- developers, behavior is at best an afterthought and often consists of nothing more than accessors: getX() and setX(x) methods (where x is some data point such as a tickerSymbol).
Why is this? I've identified two reasons; I suspect there are more.
1. Developers are most comfortable with data schemas. Data schemas for relational databases are marvelous at efficiently storing data. And because there is a well defined process for generating entity/relationship diagrams, it's perhaps no surprise that this practice bleeds through to the OO design world.
2. Developers really don't understand the domain very well. "Business rules" are often tricky things, involving multiple entities that are at times contradictory. In the real domain, these complexities and conflicts can be sorted out in the most marvelous of computing devices -- the human brain -- but even the most sophisticated of computers can afford no such ambiguities.
It's this second issue that lately has me fascinated. In domain modeling, we leap headfirst into the abyss of domain complexity with only our brains to make sense of all the separate, disparate things we encounter -- some of which we will bring into our domain model, and some that we'll exclude as irrelevant.
F. Scott Fizgerald wrote in an essay titled "The Crack-Up", "The test of a first-rate intelligence is the ability to hold two opposed ideas in the mind at the same time, and still retain the ability to function." That well describes the process of domain modeling.
Domain modeling must start with a deep understanding of the domain and for that, we must connect with domain experts. Note the plural used, for we seldom encounter any single, all-knowing domain expert. Rather, we must flush out the members of an organizations for their particular bit of the rules of the domain -- its behavior, in other words.
While we're engaged in this, we must simultaneously begin the process of reviewing and evaluating how to capture these rules in software. It's hard, hard work. It requires the mastery of several, unrelated skills that must then be integrated to produce a domain model.
Some anonymous wit once noted that "Everybody wants to go to heaven, but no one wants to die." Similarly, many want to be software architects, but few want to undergo the discipline of learning how to architect.
Just my thoughts on a Sunday afternoon.