Good Domain Modeling

In my experience, the topic of good domain modeling comes up, and people are often lacking resources that discuss it thoroughly. I have found three texts that have been extremely helpful in this area, and I would recommend reading them in this order:

1. Chapter 1 of "Java Modeling in Color With UML" by Peter Coad, which can be found online at http://www.petercoad.com/download/bookpdfs/jmcuch01.pdf
2. "Streamlined Object Modeling" by Jill Nicola, Mark Mayfield & Mike Abney (Google "Streamlined Object Modeling")
3. "Domain Driven Design" by Eric Evans (Google "Domain Driven Design")
   

Coad's book "Java Modeling in Color With UML", discusses the idea of color and explicitly modeling as classes his four archetypes:

• Description (aka "catalog-like entry"),
• PartyPlaceThing (aka "Actor"),
• Role (aka "representation of an actor in an event context"), and
• MomentInterval (aka event, action, interaction, or transaction).

Since MomentIntervals represent actions, events, transactions, or interactions, they get the hottest color: pink. The remaining colors are ordered according to decreasing temperature: Roles (participating in MomentIntervals) are yellow, Actors (playing Roles) are green, and Descriptions (describing Actors) are blue.



These ideas are a good start, but you quickly find out that they are too rigid; you cannot give a class a single color, because it participates differently in different contexts. For example, consider a "subsequent role" pattern: a role class Employee may be played by an actor class Person, but a role class Manager may be played by an actor class Employee; this implies that an Employee can be either an actor or role, depending on the context. Thus, a Manager is a subsequent role of the role Employee, and a single color and archetype will not suffice.

As a result of this phenomenon, a refinement to Coad's color modeling technique is in order. Specifically, it is not the classes that need to have a color, but it is the associations between them that need to be colored. Given the example above, you quickly realize that, if you represent the association between Person & Employee as a line (like you do in UML), then the Person side of the line should be green and the Employee side of the line should be yellow.

Streamlined Object Modeling by Nicola et al, rigorously discusses domain modeling, and presents examples in Java & Squeak (Smalltalk). The book, published in 2001, is showing its age, in that rollbacks are handled directly in code, and explicit persistence handling in the domain objects is discussed and illustrated. Today, these two burdens have been lifted, thanks to execution within a transactional context and transparent persistence, so this part of the examples and discussions can be safely ignored. Also, notably absent from Streamlined Object Modeling is the discussion of placing a domain model within an enterprise context; see Eric Evans' Domain Driven Design for such a complimentary discussion.

Streamlined Object Modeling does have a web site that is fairly static (it looks like the last update was 2002), but informative at http://www.streamlinedmodeling.com.

From the above website:

Streamlined Object Modeling pares down object modeling to just the bare essentials necessary to model business domains, business rules, and business services.

• Object think and object selection principles.
• Twelve all-encompassing "collaboration patterns" for modeling real-world relationships.
• Five kinds of business rules, three types of services, and six categories of properties.
• Rigorous methods for discovering, organizing, and implementing business rules around objects.

I hope you find these useful. They have had a profound impact on the way that I approach development, and their ideas have thus far withstood the test of time.