"Patterns provide software designers with a common vocabulary. As designers, we use patterns not only to help us leverage and duplicate successful designs, but also to help us convey ideas to developers using a common vocabulary and format."
Deepak Alur, Dan Malks, John Crupi, Core J2EE Patterns: Best Practices and Design Strategies , 2003


"One thing expert designers know not to do is solve every problem from first principles. Rather, they reuse solutions that have worked for them in the past. When they find a good solution, they use it again and again. Such experience is what makes them experts. Consequently, you'll find recurring patterns of classes and communicating objects in many object-oriented systems."
Erich Gamma, Richard Helm, Ralph Johnson, John M. Vlissides , Design Patterns, 1994


"We apply the analytic procedure in order to create a conceptual framework within which we can draw conclusions about the means by which a system solves its tasks. Indeed, we do this with the express purpose of establishing a solid foundation from which we can carry out a subsequent synthesis. This synthesis, in turn, acts to verify the conceptual model as an explanation. The process is an iterative one."
Tom Ritchey, Refactoring, 1991,


"The structure of a software system will reflect the communication structure of the team that built it."
R. E. Fairley


"If you can't explain it simply, you don't understand it well enough."
Albert Einstein


"Our failure to master the complexity of software results in projets that are late, over budget, and deficient in their stated requirements."
Grady Booch, Object-Oriented Analysis and Design, 2007


"The fundamental task of the software development team is to engineer the illusion of simplicity"
Grady Booch, Object-Oriented Analysis and Design, 2007


"Abstraction can reduce complexity by spreading details across a network of components"
Steve McConnell, Code Complete: A Practical Handbook of Software Construction, 2007


"Use models to find out how things work or to find solutions to puzzling dilemmas. Create models to communicate ideas and understand things you can?t see. Recognize models and the countless ways models are used for working, playing, teaching and explaining. Assess models for what they do and don't tell you about the real thing and how useful they are"
Boston Science Museum


"It usually takes more than three weeks to prepare a good impromptu speech."
Mark Twain


"Simplicity is the final achievement. After one has played a vast quantity of notes and more notes, it is simplicity that emerges as the crowning reward of art."
Frederic Chopin


"Important developments often arise out of analogies. By comparing a topic you understand poorly to something similar you understand better, you can come up with insights that result in a better understanding of the less-familiar topic. This use of metaphor is called 'modeling.'"
Steve McConnell, Code Complete: A Practical Handbook of Software Construction, 2007


"Man will occasionally stumble over the truth, but most times he will pick himself up and carry on."
Winston Churchill


"Sometimes creativity just means the daily work of helping others to see a problem in a different way."
Joseph Badaracco


"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
Martin Fowler, Refactoring, 1999


"... he [Ralph Johnson] brought out the point that architecture is a subjective thing. A shared understanding of a system's design by the expert developers on a project. Commonly this shared understanding is in the form of the major components of the system and how they interact. It's also about decisions,..."
Martin Fowler, Patterns of Enterprise Application Architecture, 2003


"We all want our software systems to be fast, reliable, easy to use, readable, modular, structured and so on. But these adjectives describe two different sorts of qualities. On one side, we are considering such qualities as speed or ease of use, whose presence or absence in a software product may be detected by its users. These properties may be called external quality factors. ... In the end, only the external factors matter. ... But the key to achieving these external factors is in the internal ones..."
Betrand Meyer, Object-Oriented Software Construction, 2000


"Our primary tool for design is abstraction. It allows us to effectively use encapsulation, inheritance, collaboration, and other object-oriented techniques."
Rebecca Wirfs-Brock, Alan McKean, Object Design: Roles, Responsibilities, and Collaborations, 2002


"... the most significant complexity of many applications is not technical. It is in the domain itself, the activity or business of the user. When this domain is not handled in the design, it won't matter that the infrastructural technology is well conceived. A successful design must systematically deal with this central aspect of the software."
Eric Evans, Domain-Driven Design: Tackling Complexity in the Heart of Software, 2003


"Object modeling addresses the 'what' of the business; its concern is only with what is to be built, never why or how. Prior to the object modeling session, a good object architect inquires about the 'why' questions, and raises a red flag if no one at the client site knows the answers. Clients not clear on their strategy are not ready to discuss what they want to build."
Jill Nicola, Mark Mayfield, Mike Abney, Streamlined Object Modeling: Patterns, Rules, and Implementation, 2001


An object modeling technique, 'modeling in color' helps identify and define robust, extensible, problem domain classes for a software component, application, or system.

Software developers working in object-oriented programming languages including Java, C#, and Objective-C create software as a set of related classes. Each class defines a different kind of object, and it is objects of these classes collaborating with each other that provides the required function of the software.

According to the 'single responsibility principle' or the principle of 'separation of concerns', the objects of a well-designed class do one thing and only one thing. Some classes are represent technical concepts such as user interface windows, pages, and controls, database connections, search results, and transactions, and network connections, services and messages. Other classes represent  a problem domain concept. The prpbelm domain is the activity or area of interest of the users or customers of the software. For example,  if we are building an order management system, we would typically define problem domain classes to represent customers, orders, and productsamong others.

We sometimes refer to these classes as  defining business objects or modelling 'real world' concepts but problem domain classes (pd classes for short)  or just domain classes has become the generally accepted name for such classes.

In other words, problem domain classes model the concepts, ideas and rules within our software that are left after stripping away the stuff specific to the technologies we are using. They form the heart of a piece of software and are the most important logical layer in a conventional object-oriented software application, or system.

In more component-based or service-oriented software, problem domain classes help drive the definition and organization of business services and components. They also help drive the design of the problem domain classes used in the internal implementation of a component or service.

Regardless of whether the software is conventional, component-based, or service-oriented, nearly all modern software architectures require a significant number of technology classes to support each problem domain class. As shown in figure 1:

  • User interface classes, typically organized as some variant of the venerable Model-View-Controller and Command patterns, cater for the display and manipulation of pd objects by human users of the software.

  • Persistence classes, or configuration files for a persistence mechanism such as Hibernate, ADO.Net Entity Framework, and Core Data, handle the mapping, storing and retrieving of pd objects from files on disk or relational database.

  • Classes for services (web, API, etc) and their parameters provide the means for other components, or external systems to integrate and interact with pd objects across a network.

A PD class and typical set of related technology classes

Figure 1: A PD class can require a significant number of supporting technology classes

While not every pd class requires so many supporting technology classes, significant pd classes may require more because they appear in multiple views, participate in multiple services, and be persisted in different ways at different times. The whole thing is further complicated by the relationships and dependencies between pd classes, such as the products within a sale for a customer, or the items in a delivery made by a supplier. The average number of supporting classes for a pd class can easily reach a dozen or more. This is without considering any related unit, integration and system test classes and scripts.

Despite best-practice encapsulation, changes to a pd class frequently ripple through the supporting classes. Small refactorings (renaming an operation for example) are automated within modern integrated development environments (IDE) such as Eclipse, NetBeans, Visual Studio and XCode. More significant changes (removing an attribute, changing a relationship from one-to-one to one-to-many, making a relationship bi-directional, for example) still typically require manual updates and retesting of a number of classes, configuration files and required supporting artifacts.

Some amount of change is inevitable, but any patterns or strategies that enable earlier identification of more robust problem domain classes are obviously worthwhile learning. This is precisely what the 'modeling in color' technique provides, especially for business and industrial I.T. components and systems.

First used on a major Java software development project in Singapore in 1997 and building on his previous work on object-oriented analysis and design patterns and strategies, Peter Coad, researched and refined the technique over the next couple of years. In 1999, Peter Coad, and co-authors, Eric Lefebvre, and Jeff De Luca, published an introduction to technique in their book, Java Modeling in Color with UML. Other acknowledged contributors to the technique and related FDD process include Phil Bradley, Jon Kern, Mark Mayfield, David North, and myself.

Class Archetypes

The modeling in color patterns and strategies are built around the idea of class archetypes.

In business systems, the same general kinds of significant problem domain class keep appearing, no matter what the domain. For example, we nearly always find classes that represent business transactions or interactions of different types such as sales, orders, rentals, bookings, scheduled events, deliveries, submissions, approvals, inquiries, etc. Then we generally find classes that model the parties, places, and things that participate in those business transactions or interactions, the people or organizations doing the buying, selling, ordering, submitting, approving, etc. In addition, the products and services being bought, sold, approved, etc., need to be represented, as do the places like shops, bank branches, websites, etc., where all this happens. These general kinds of classes are not specific to a domain. It does not matter whether the problem domain is banking, insurance, retail, manufacturing, human resources, travel, transportation, or something else, the same general kinds of classes keep on appearing. The different kinds of class are independent of the domain. They are domain neutral.

It is not just business systems where these kinds of class appear. In industrial systems we have classes modeling specific types of event and intervals of time such as changes in state of a sensor or switch, a period of time over which a measurement is taken, the length of time a piece of equipment is ramping up to a certain level of performance, and so on. Again, there are also typically, party, place, and thing classes representing the sensors and devices themselves, human operators supervising the equipment or process in question, and the locations of the various pieces of equipment, etc.

The similarities between all the classes of one of these rough categories are not close enough to be generalized into a useful superclass or Java/C#-style interface. However, the similarities are close enough for them to help guide the choice and definition of problem domain classes in our designs. Modeling in color calls these rough categories, class archetypes, the term archetype supposedly representing a less rigid pattern and, therefore, being a more appropriate term than stereotype. Modeling in color recognizes four class archetypes and assigns each a color.

The four class archetypes

Figure 2: Modeling in color defines four class archetypes for problem domain classes

The four class archetypes as shown in figure 2 are:

  • The Moment-Interval class archetype that models something that one needs to work with and track for business and legal reasons, something that occurs at a moment in time or over an interval of time. [Coad99]

    Examples of Moment-Interval classes include Sale, Rental, Order, Journey, Flight, Meeting, Booking, Murder, Sensor Reading, Alarm Activation, etc.

    Moment-Interval classes are pink (pastel red). They represent happenings that take place that our software is interested in, interactions and business transactions between people, places and things.

    In other words, if it happens, it is pink! Pink happens!

  • The Role class archetype that models a way of participation by a party (person or organization), place or, thing. [Coad99]

    Examples of role classes include Applicant, Account Holder, Approver, Pilot, Cashier, Customer, Supplier, Operator, etc.

    Role classes are pastel yellow in color. They represent recognizable ways that people, places, and things participate in moment-intervals (happenings) in our software. Roles are sets of responsibilities and duties that we are able and authorized to perform. We often talk about ourselves as wearing multiple or different hats when we are expected to perform multiple or different roles. Role classes model those hats, and those hats are always yellow. 

    We wear yellow hats!

  • The Party, Place, Thing class archetype that models someone or something who plays different roles.[Coad99]

    Examples of Party classes are Person and Organization. Examples of Place classes  include Office, Store, Warehouse, Airport, Bank Branch, etc. Thing classes are those that identify individual items such as individual cars, airplanes, DVD's, books, pieces of equipment, etc.

    Party, Place, Thing classes are pastel green in color.  If Role classes are the different (yellow) hats that can be worn, then Party, Place, Thing classes are the wearers of those hats. Obviously, people play roles but places can too. A building might have a role as a restaurant another as a crime scene. Things can also play roles, a role in a manufacturing process, and a role in a sales process, for example. If it you can converse with it, be taken to court by it, move it, kick it, sit on it, or stand in it, then it is likely to be a green Party, Place, Thing.

    Hats are yellow but those that wear them are green!

  • The Description class archetype that models a catalog-entry-like description. It is a collection of values that apply again and again. It also provides behavior across the collection of all things that correspond to its description. [Coad99].

    Examples include classes representing product descriptions of all kinds. The difference between a blue and green is the difference between a film and the DVD's on which the film is recorded.

    Description classes are pastel blue in color. Description classes categorize or label other stuff depending on different values, typically objects of Party, Place, Thing classes but occasionally Moment-Intervals too. The industries that companies work within are objects of a Description class. The models of a car in a show room are objects of a Description class. The titles of books sold by Amazon.com are objects of a Description class.

    The labels you use to catalog stuff like this, are always blue!

Typical Responsibilities

Because classes of the same class archetype model roughly the same sort of thing, their objects generally need to remember similar sorts of bits of  information and perform similar sorts of tasks. For example, objects of a Moment-Interval class generally remember the date and time they occurred and can tell you if they completed successfully or not. Objects of a Role class typically need to remember some sort of identifier they have been given that authorizes them to perform that role, a pilot's license number, for example, and so on.

By examining numerous examples of each class archetype and generalizing slightly we can create a rough list of typical operations and attributes for each class archetype. Each attribute or operation in the list represents a typical kind of operation or attribute that we might expect to define for classes of that archetype (see Figure 3).

The four major class archetypes with their typical attributes and operations

Figure 3: The four class archetypes each have typical attributes and operations

Few if any of the classes in a particular model will have examples of all the typical attributes and operations of their class archetypes. If a particular typical attribute or operation is not relevant for a specific class we simply do not define an equivalent attribute or operation for that class. For example, some Moment-Interval classes need the concept of relative priorities and will have the equivalent of a priority attribute. Other Moment-Interval classes do not.

Each typical attribute or operation of a class archetype may match multiple attributes or operations on a specific class. For example a Moment-Interval may need both a major and minor status attribute if it has a complex lifecycle.

The lists of typical attributes and operations are not exhaustive either. Our classes will attributes and operations that are not in the relevant archetypes list. For example a Party class modeling an individual person may contain a retention date indicating when data must be erased to comply with some legal requirement. No equivalent for this attribute exists in the Party, Place, Thing class archetype.

The typical attributes and operations of a class archetype are simply a list of suggestions for specific attributes and operations that we might need in our actual class definitions. They act as prompts and hints of things we should consider when creating or reviewing a class belonging to a particular class archetype.

Another way to think of this is that each operation or attribute of a class archetype acts as a reminder of a typical responsibility for classes of a particular class archetype. If we can identify the class archetypes of the classes in our problem domain, the lists of typical operations and attributes give us a check-list that can help us review or place responsibilities appropriately in our own models. For example, the first attribute in each of the class archetypes is some sort of identification or reference number. This reminds us that objects of classes belonging to any of the class archetypes have a responsibility to enable themselves to be matched to the real-world object that they represent. For example, a cash sale object will typically remember a receipt number as its reference number so that it can be matched to the particular transaction it models. Objects representing cashiers may be required to remember a user name to match them to their human counterparts when they login, and so on.

The fact that class archetypes have a name, a list of typical attributes, and a list of typical operations means we can represent class archetypes graphically in the Unified Modeling Language (UML). We simply reuse the same notation as we do for the specific classes that belong to the class archetypes, as shown in Figure 3.

Model Archetypes

To fulfill their responsibilities objects frequently need to collaborate with objects of the same or other classes. Therefore, many of the typical responsibilities in class archetypes imply typical associations with other classes and typical ways of interacting with objects of other classes. These typical associations and typical interactions of their objects enable us to combine class archetypes into archetypal, problem-domain object models. These model archetypes or domain neutral components act as general repeating patterns for our analysis and design models.

Basic Model Archetype

Figure 4: The four class archetypes link together into the basic model archetype


The Domain Neutral Component


Figure 5: The basic model archetype expands for each flavor of Party, Place and Thing into a larger Domain Neutral Component

Using the Domain Neutral Component (DNC) can really help speed up the building of our problem domain object models. Start by identifying one or more Moment-Interval classes in the particular problem domain of interest. Then for each of these in turn, overlay the DNC. Step through each item in the DNC turn replacing it with items specific to this particular problem domain or dropping it if there is no equivalent in this problem domain or it is simply not needed in model.

The DNC can also be very useful in reviewing existing models. First, color in the model by assigning archetypes to each class. Then challenge and justify deviations and omissions from the DNC. However, remember that the DNC is a pattern not a meta-model. A meta-model defines a rigid set of rules for creating compliant models. The DNC does not do this. It is much looser, a set of suggestions and hints. Justifiable deviations from the pattern are allowed, expected, and essential in many cases.

When they first encounter it, many people, are a little skeptical about how applicable the DNC is in practice. I certainly was. There are two reasons I think that the DNC is much more applicable than maybe first expected. Firstly, most business systems are centered on a particular business event or activity or a flow of events and activities in the form of a business process. The Moment-Intervals model these business events and activities. For each business event and activity there are typically different people or organizations involved in different ways. The events and activities usually take place at some location even if, these days, that location is somewhere in cyberspace. Frequently business events and activities are about buying, selling, assigning, and moving things. The Roles and Party, Place, Things model the who, where and with what of the business events and activities. The Descriptions model different sets or categories of the Party, Place, Things involved in the events and activities. In addition, the emphasis on the Moment-Intervals first, followed by Roles, role players , and Descriptions helps counter a tendency to center things around and concentrate too much on role players as one might in more traditional Entity-Relationship Diagramming (ERD).

The second reason why I think that the DNC is much more applicable than maybe first expected is a line of thinking triggered by a discussion with an old colleague of mine from TogetherSoft and Borland, Karl Frank. When you step back and think about it for a while, you realize that the DNC is in essence a natural expansion of a UML association between Party, Place and Thing classes. The Moment-Intervals are similar in many ways to the idea of an association class and the Roles are a similar idea applied to the role names found on the ends of the association.

Over the years, I have incorporated a number of minor changes to the DNC in comparison to that presented in the Java Modeling in Color with UML book. Read more about these changes...

Color Coding Class Archetypes

Although class and model archetypes can obviously be effective without color, it is the color coding that gives the technique its name. The color coding has proved so beneficial in practice that it is well worth the little extra effort required to use it.

The color makes it easier to learn and remember the class archetypes. It also makes the class archetypes easier to identify in a non-trivial UML class or sequence diagram. When you are new to object modeling or not frequently involved in object modeling, it can be very off putting when first presented with a complex diagram. The color makes it easier to engage with the diagram. This helps people such as a project's customers and end users contribute better in the modeling process. For example, they can easily identify and initially focus on pink Moment-Interval classes representing the business interactions they are interested in and work outwards from there.

Much of the benefit derived from using object-modeling techniques is in the ability to communicate complex analysis and design more easily (something that seemed frequently forgotten and lost in the long, detailed object modeling phases of the late 1990's and the subsequent design of the UML 2.x specification). The careful use of color dramatically increases that ability for UML class and sequence diagrams to communicate.

For those interested in why the use of color works so well, Color Coding Class Archetypes has a further discussion on the use of color, including what colors to use for each class archetype.

For most, it is enough to learn and remember that the four class archetypes are usually assigned the following colours:

  • Moment-Interval classes are a pastel shade of pink.
    Pink happens!

  • Role classes are a pastel shade of yellow.
    We always wear yellow hats!

  • Party, Place, Thing classes are a pastel shade of green.
    The wearers of the yellow hats are green!

  • Description classes are a pastel shade of blue.
    You give stuff blue labels!

Next Steps

Armed with the general appreciation of the technique and ideas behind it, it is time to delve a little deeper and uncover more about each of the four class archetypes:


Deliver frequent, tangible, working results
Peter Coad, c2.com/cgi/wiki?PeterCoad
Four Logical Layers
One of the most common initial strategies for selecting the types of object needed in a software system, service or component is to define a set of logical layers into which we can place candidate classes. There are various layering schemes but they are generally variations of a similar theme. The problem domain or business layer is the most important.
Read more about this...

Accelerated Problem Domain Analysis
Peter Coad's 'Modeling in Color' technique uses the idea of class archetypes to build understanding of a problem domain quickly. Jeff De Luca's Feature-Driven Development approach defines a collaborative process that works beautifully with modeling in color. Domain experts and developers work together on a daily basis to build an overall, initial, 'just enough' domain model that is then used to build a much better initial product backlog or features list.
Read more about this...

The Moment-Interval Class Archetype
Modeling in color defines four archetypes. The first of these, the Moment-Interval class archetype, models something that one needs to work with and track for business and legal reasons, something that occurs at a moment in time or over an interval of time. It represents significant interactions between people, places an things. If something happens and we are interested in it, it is usually an object of a Moment-Interval class.
Read more about this...

The Role Class Archetype
The Role class archetype is the second of the four class archetypes defined by the modeling in color technique. Role classes model a way of participation by a party (person or organization), place or, thing. We sometimes talk of people wearing more than one hat when they have multiple responsibilities. Roles model those hats.
Read more about this...

The Party, Place, Thing Class Archetype
The third of the four class archetypes defined by the modeling in color technique, is the Party, Place, Thing class archetype. These classes model someone or something who plays different roles. They are the role players. If Roles classes are the hats, then Party, Place, Thing classes are the hat wearers. If you can converse with it, pick it up, or stand in it, then it is likely to be an example of a party, place or thing.
Read more about this...

The Description Class Archetype
The fourth and last class archetype defined by the modeling in color technique, is the Description class archetype. This class archetype models a catalog-entry-like description. It is a collection of values that apply again and again. It also provides behavior across the collection of all things that correspond to its description. It categorizes objects of other classes according to different values.
Read more about this...

Typical Responsibilities of Moment-Intervals
Like all the class archetypes in modeling in color, the true usefulness of the Moment-Interval class archetype in identifying and reviewing problem domain classes is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.
Read more about this...

Typical Responsibilities of Roles

Like all the class archetypes in modeling in color, the true usefulness of the Role class archetype in identifying and reviewing problem domain classes is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.
Read more about this...

Typical Responsibilities of Party, Place, Things
Like all the class archetypes in modeling in color, the true usefulness of the Party, Place, Thing class archetype in identifying and reviewing problem domain classes is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.
Read more about this...

Typical Responsibilities of Descriptions
Like all the class archetypes in modeling in color, the true usefulness of the Description class archetype in identifying and reviewing problem domain classes is due to its typical responsibilities, and the lists of typical attributes, operations and associations that represent those responsibilities.
Read more about this...

Model Archetypes and Domain Neutral Components
Linking together the typical associations between class archetypes presents us with a pattern of classes we call a model archetype or domain neutral component. We can display this with the Party, Place, Thing class archetype as a single class to give a basic model archetype. Alternatively we can explode the Party, Place, Thing class into its three flavors and produce a larger more comprehensive domain neutral component that is even more useful. Model archetypes can be used to rapidly build new problem domain models or review and revise existing problem domain models.
Read more about this...

Class Archetypes, UML and Color
Class archetypes can be used without the color coding quite happily. Color can be used to highlight items in diagrams with great effect without the use of class archetypes. The combination of the two, however, provides a much deeper means of communication. The color-coding 'layers' into the diagram. It provides a means to quickly and effectively engage with a non-trivial diagram.  You can 'step back' from the diagram and examine the patterns of linked colored classes, 'zooming in' on textual detail as needed. After modeling in color for a while, you wonder how you were ever satisfied with black and white diagrams.
Read more about this...

From UML Association to the Domain Neutral Component
Karl Frank and I were in Denver, USA, giving a modeling in color workshop for a client. One evening Karl asked me what if any relationship I thought there was between roles in the Domain Neutral Component (DNC) and role labels on a UML association. The subsequent discussion sparked a train of thought that further convinced me of the simple, effectiveness of using the domain neutral component.
Read more about this...

Reference Number Attributes in Class Archetypes
Each of the four class archetypes has a set of attributes that we might typically expect to find in classes belonging to that archetype. In each case, this set includes some sort of reference number attribute. While they all might seem very similar, and serve similar purposes, some subtle differences exist.
Read more about this...

Historic Values
In business software it is often necessary to remember the values of objects at the time a business transaction took place. For example, the price of a product may change over time and it may be necessary to remember the price used in a sale of the product. There are two fundamentally different ways of satisfying this requirement and a good number of variations between the two extremes
Read more about this...

Moment-Intervals and GoF State Pattern
The Moment-Interval class archetype lists a status attribute as a typical attribute for this kind of class. The Gang of Four State pattern provides an alternative to a simple attribute for implementing state-driven behavior. In fact, there are a number of interesting comparisons and differences between the GoF State pattern and Moment-Interval classes that can be made.
Read more about this...

Modeling People, Organizations and their Names and Ids
People! They make things so complicated! Some days it seems like the only thing more frustrating than people, are the organizations that they have created or for which they work. Producing software that models people and organizations flexibly and efficiently is a real challenge even when using modeling in color.
Read more about this...

FDD and 'modeling in color' Workshops
Help give your next software development project a better start, or correct the course of a wayward project. Now available in the USA, UK, and continental Europe.
Read more about this...

Free 'Modeling in Color' Resources

'Modeling in Color' support for a number of popular UML modeling tools
Read more about this...
Follow me on Twitter...