Modeling in Color (MIC)
Each class in any problem domain maps to one of four class
archetypes and follows more or less the same form as the
archetype from which it was cast. Archetypes also serve as a categorization of the
responsibilities, methods and attributes of a class. For example, each archetype includes a
‘number’ attribute of a given type to distinguish it from the other
archetypes. Consider the semantics of ID numbers.
A Moment-Interval (MI) has a ReferenceNumber, e.g. every sales
transaction must provide a Reference Number for legal reasons. Role
has an AssignedNumber provided by some authority such as the FAA for
a pilots license. A Party, Place or Thing (PPT) has an
IdentityNumber, e.g. each manufactured vehicle has a VIN ID. And
finally Description has an ItemNumber, e.g. for each item on the
shelf in a store. Hence, the Reference, Assigned, Identity, and Item
number attributes provide a link between the archetype and the
artifact it represents in the problem domain.
The four class archetypes have a
natural tendency to assemble themselves into a general pattern
called the "Domain Neutral Component" (DNC). Hence, when
modeling in color we look for four
categories of class archetypes from objects in our problem domain
and connect them based on the DNC to guide the construction of the
domain model.
The Domain-Neutral Component (DNC) serves as a starting point and reference for a domain-specific model
- the model of the problem to be solved. The DNC has the form shown below.
Here are some examples of models built using the MIC
method. I recommend that you reference one of these diagrams during
the discussion. For browsers with Vector Markup Language support, click VML,
otherwise GIF.
Modeling is by its nature a visually oriented activity and so it
makes sense to use pre-defined colors to add another dimension that
increases the amount of information contained within. Color enables
us to see patterns from a distance. This means a model diagram can
convey both an overview and low-level details without having to
break the visual context by using another diagram type. Also,
because our brain instantly associates a color with an archetype
whose characteristics we know, we can effectively speed-read a
model.
The four archetypes are identified by name and color
as follows:
- Moment/Interval (pink)
is a class related to a
"moment in time" or "an interval of time" that must be
tracked for business, legal, or technical reasons.
Moment-intervals (MIs) are the strong forces that tie a domain
model together and they often encapsulate the most interesting
methods. Examples of MI activities that
happen at an instant in time or over a period of time are:
moment of a sale
(i.e. a transaction), an electronic money transfer, the
interval of a
video rental, tracking of an aircraft from detection to landing,
warranty period of a product, and duration of
a hotel room reservation. The key thing to recognize is that you
have one of these two - a moment in time or an interval of time;
don't worry about whether it is one or the other, either way,
its a pink class which is always cognizant of the time and date,
the reference
number of each event, its total, its transaction status, and its priority. It
will have methods such as totalSaleValue, isComplete,
isUrgentDelivery. As a rule of thumb during analysis, focus on
the MIs and move outwards from hot (pink) to cold (blue).
- Role (yellow)
normally represents
the way a Party (person or organization), Place, or Thing (PPT)
participates in a MI event or activity. For example a Person
(perhaps the same person in a one-person Company) can play the
role of Cashier, Owner, and Mechanic. In a financial domain, a
Customer can play several roles such as Applicant, Depositor,
Borrower, or Investor. Role classes enable reuse of PPT (green)
classes by factoring out transaction behavior specific to a
given Role-MI association. The decoupling capability provided by
roles allows cleaner, simpler PPT classes to be developed.
Yellow roles can also be asked about
availability to play a given role, although this information is
probably contained in the associated descriptor (blue) class.
For example, an Airport currently performing a Military Role may
not be available for a Passenger Role.
- Party, Place, Thing (green):
A PPT is a uniquely identifiable entity (a tangible noun) found in the
vocabulary of the problem domain. PPTs are the worker classes in
a system representing key assets and as such have the highest
desirability for re-use across applications in a specific
domain. In order to enable reuse, PPTs (greens) need to be
decouple from infrastructure details by roles (yellows). In some
cases a PPT does not need a Description class. For example, you
would not attach a Description to a PPT just to hold a category
attribute.
- Description (blue):
is
catalog-like description of an object; a set of values that
apply again and again. It is useful to think of the
description archetype as a table-driven class or knowledge
layer. Descriptions provide information such as meta-data,
enumeration, business-rules, and policies for the classes they support and contain a standard plug-in interface to
connect to different databases and algorithm components.
Descriptions often include methods like “how many are available”
and “calculate total for quantity”. Whether a particular
object can
play a specific role or not is determined by the rules in its
Description class. Descriptors are normally attached to PPTs,
however both Moment-Intervals and (to a lesser extent)
Roles can technically have Descriptors if
meta-data about them is important. The use of Descriptors is a flexible
alternative to class inheritance; it is loosely coupled and can
potentially be changed at runtime.
Why build a domain model?
A good domain model provides a solid framework around which
clients, analysts and developers can discuss requirements
objectively. More precise than written or verbal communication, a
good domain model helps avoid many of the costly
misunderstandings and miscommunications between the business and
the software development team. In addition, a domain model is
less detailed than a programming language, in which case it can
be read and evaluated by non-technical members of a project team.
In a modern software development process, the map makers
(architects) explore the land (the problem domain) with people
who live in it (the domain experts) and together they produce a
map to serve as the bridge between the problem domain and the
solution domain. Hence, a domain model is like the road map that
guides the development journey; without this reference your
project can very quickly end up getting lost. To use a different
metaphor, the domain model is the steel and concrete framework of
a large building within which you build everything else. You
might not need one when building a garden shed, or even a basic
house, but for a skyscraper, success will be limited and very
temporary without one. The domain model helps maintain the
conceptual integrity of the software system just as the steel and
concrete help maintain the structural integrity of the
skyscraper. Using a domain model as a guide, developers can produce
better software faster.
How do I determine which archetype a class belongs to?
For each class ask yourself the following questions in the order
provided until you either answer "yes" or reach the end of the
list.
- Does the class represent a time-relevant activity that
needs to be tracked for business, legal, or technical reasons?
If yes, then color it pink, it belongs to the MI archetype.
- Does the class represent a role being played by a party
(person or organization), place, or thing? If yes, then color it
yellow, it belongs to the Role archetype.
- Does the class represent a catalog-entry like description
that can be applied again and again to instances of the same
class?
If yes, then color it blue, it belongs to the Description
archetype.
- Color the class green, it belongs to the
PPT archetype.
The MIC method allows for the existence of "plug-in" interfaces
to extend Description archetypes with algorithms and data
providers. Plug-in interfaces are white.
Summary
The domain-model describes the problem, not the solution.
Each class in any problem domain is cast from one of four class archetypes.
The archetypes have a natural tendency to assemble themselves into the DNC pattern.
Color enables us to speed-read models.
A good domain model avoids costly misunderstandings between business and IT departments.
Using a domain model as a guide, developers produce better software faster.