ColdFusion Community

The online ColdFusion / CFML community website

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:

Class: Stock
- 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.

Views: 16

Add a Comment

You need to be a member of ColdFusion Community to add comments!

Join ColdFusion Community

Comment by Hal Helms on November 10, 2008 at 13:33
That's where the value of determining what type of object you're dealing with comes in, Andrew. Objects that have little to no behaviors are often called "value objects". Objects that exhibit behaviors are called "entities". The problem isn't that we use value objects when appropriate but that everything ends up being a value object and all logic is placed either into the application layer or the "service" layer.

I'll write another post this week on the need for a shared vocabulary (Evans calls it a UBIQUITOUS LANGUAGE) with which we can discuss domain models among developers and domain experts.
Comment by Andrew Kamphuis on November 10, 2008 at 2:25
Hal, Good comments as always.

So what do you recommend for people (like myself) where most of their domain model is just data and not behaviours? We deal with Products and Shopping Carts and while a Shopping Cart has a ton of behaviors such as calculateShipping(), calculateTax(), etc, products don't really have any behaviors - it's just a bunch of data. So I know that anemic objects are suppose to be bad, but how do you deal with that?


Latest Activity

kanth posted a blog post

ColdFusion Application Development by ColdFusion Programmers & Developers

ColdFusion application development is associated with the website development. With the unique features of the ColdFusion development along with the ColdFusion Makrup Language which resembles scripting components like JSP and PHP and even ASP but it bares the most resemblance to HTML syntax. The ColdFusion allows developers to develop content publishing systems, dynamic sites, ecommerce sites, self service application and much more.…See More
Jul 30
Isaac Dealey updated their profile
Jul 29
Thomas Bishop updated their profile
Jul 29
Profile IconBecky B, kanth, Jim Bossemeyer and 15 more joined ColdFusion Community
Jul 29
Dennis Matteson updated their profile
Jun 22
Ben Koshy updated their profile
May 2
Ben Arledge updated their profile
Mar 8
Santhosh Kiran Reddy shared Mark Drew's group on Facebook
Mar 1


Translate this page

© 2014   Created by Nick Tong.

Badges  |  Report an Issue  |  Terms of Service