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: 18

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

Alex Kaniaru joined Mark Drew's group

CFEclipse Users

For people that love using the IDE that is Eclipse with the awesome plugin of CFEclipse
Apr 22
Alex Kaniaru liked Russ Johnson's group ColdBox
Apr 22
Alex Kaniaru joined Russ Johnson's group


Community group for the ColdBox framework.
Apr 22
Ashutosh Verma liked Raghuram Reddy Gottimukkula's blog post My Experience with Coldfusion Builder
Mar 2
Harmindra Sirohi updated their profile
Feb 18
Harmindra Sirohi posted a status
Feb 18
Isaac Dealey posted a discussion

PayPal Cart Integration

Hey guys,I know I haven't been on here in a little while. I'm hoping one of you will have some information on this...A client of mine asked me to integrate PayPal into their existing custom shopping cart. It's just the typical old PayFlow-style, send the browser to PayPal and then bring them back afterward. I read through all the documentation and I've got it creating the form and sending to PayPal and it all works.Now PayPal says form encryption is not required, although they also say you…See More
Jan 2
Isaac Dealey updated their profile
Jan 1


Translate this page

© 2015   Created by Nick Tong.

Badges  |  Report an Issue  |  Terms of Service