Skip Navigation Links > Modeling > MIC

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.

DNC pattern

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.



Quote Start The domain-model describes the problem, not the solution.


Quote Start Each class in any problem domain is cast from one of four class archetypes.


Quote Start The archetypes have a natural tendency to assemble themselves into the DNC pattern.


Quote Start Color enables us to speed-read models.


Quote Start A good domain model avoids costly misunderstandings between business and IT departments.


Quote Start Using a domain model as a guide, developers produce better software faster.