Peter Coad's 'Modeling in color' defines four class archetypes. A model archetype is a typical structure of collobaorating classes that guides the rapid construction of robust domain object models.

'Modeling in Color' is an analysis and design technique for quickly and robustly identifying classes of domain object and assigning system responsibilities to those classes. The technique defines four class archetypes each of which represents a rough category of class found over and over again in object-oriented and service-oriented software. The four class archetypes 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]

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

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

  • 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 ]

Typical Responsibilities Imply Typical Collaborations

To fulfill their typical responsibilities, objects of classes belonging to a particular class archetype collaborate with other objects. These other objects may be of classes belonging to the same class archetype or classes belonging to another class archetype. For example:

  1. One of the typical responsibilities of objects of a description class is to findAvailable, locating one of the objects that it describes that is available to play a particular role in a moment-interval. In a car hire scenario, a CarType description object would interact with Car thing objects and CarRental moment-interval objects to find a car of the correct type that is available for hire.

  2. One of the typical responsibilities of objects of a role class is to assessAcrossMIs,computing some sort of performance assessment from the moment-interval objects in which its role-player has participated in that role. In a sales scenario, objects of a SalesPerson role class would collaborate with objects of a Sale moment-interval class to determine if the sales person has achieved their sales target this quarter.

Brevity vs. Precision

When talking about class archetypes, there is a frequent need to write phrases like, 'an object of a class belonging to the X class archetype'. As can be seen above, this very quickly becomes tiresome. Therefore, while the object-speak police might not like it, it is usual to truncate phrases like this to only the name of the class archetype. For example, the phrase, 'roles interacting with moment-intervals' is short-hand for 'objects of classes belonging to the Role class archetype interacting with objects of classes belonging to the Moment-Interval class archetype'. While the short-hand form lacks some precision, this is not often a problem because the context makes clear what is meant. In practice, the brevity of the short-hand form is more manageable and results in more effective communication, the names of the four class archetypes rapidly entering a team's shared vocabulary.

Using the short-hand form, the examples can be rewritten slightly more concisely as:

  1. One of the typical responsibilities of a description is to findAvailable,locating one of the people, places, or things that it describes that is available to play a particular role in a moment-interval. In a car hire scenario, a CarType description would interact with Car things and CarRental moment-intervals to find a car of the correct type that is available for hire.

  2. One of the typical responsibilities of a role is to assessAcrossMIs, computing some sort of performance assessment from the moment-intervals in which its role-player has participated in that role. In a sales scenario, a SalesPerson role would collaborate with Sale moment-intervals to determine if the sales person has achieved their sales target this quarter.

The typical collaborations between class archetypes imply typical associations between classes.The SalesPerson example above (2) implies that a Role class will typically be associated with the Moment-Interval classes that it participates in and, over time, a Role class will usually participate in a number of the same kinds of Moment-Intervals. Therefore, there is typically a one-to-many association between a Role class and Moment-Interval class.

 Another example is Party, Place, Thing classes that obviously need to be associated with the Role classes that model the way they participate in Moment-Intervals. Typically for each of the Roles that a Party, Place Thing might play they either play the role or do not. Therefore, the association between a Party, Place, or Thing class and a particular Role classes is most often a one-to-zero-or-one relationship.

Description classes usually categorize Party, Place, or Things classes and each instance of the Description class describes zero or more objects of the associated Party, Place, or Thing class. Therefore, there are typically many-to-one associations between Party, Place or Thing classes and Description classes.

These typical associations can be shown in a UML class diagram using four classes to act as placeholders for each of the class archetypes. This leads to the class diagram in figure 1 adapted from [Coad 99].

The Four Class Archetypes and Typcial Associations

Figure 1: The Four Class Archetypes and Typical Associations


Who, Where and What

The obvious questions to ask about a Moment-Interval are when, where, who, what, and why? Through the roles that they play, the Party, Place, Thing class archetype provides us with answers to these questions:

  • Who is involved with a particular Moment-Interval? This is answered by Party classes via the roles they play.
  • Where is this Moment-Interval occurring? This is answered by Place classes via the roles they play.
  • What else is involved in or affected by this Moment-Interval? This is answered by Thing classes via the roles they play.

Why

The question of when is answered by the date and time responsibility of the Moment-Interval class represented by the dateOrDateTimeOrInterval attribute. That leaves us with the why.

The question of why is a little harder to answer as it is often implicit form the context or unimportant from the software's perspective. For example, we may not need to understand why a particular sale was made beyond the fact that the buyer needed or wanted to make the purchase. Even if it would be nice to do so, it can be hard to elicit this sort of information. However, where we can and if we need to, the answer is provided by the purpose responsibility of the Moment-Interval class represented by a purpose attribute.

Cause and Effect

In some cases, the whole of a system revolves around a single kind of Moment-Interval but mostly there are several different kinds of Moment-Interval that need to be modeled. Some Moment-Intervals naturally follow others and the Moment-Interval classes of a system can be associated to each other in one or more flows of time. For example, a Moment-Interval modeling a Delivery would follow and be related to a Moment-Interval modeling the Sale for which the delivery is needed.

When you consider that the name of a Moment-Interval class is often the noun form of a business activity or action (e.g. Sale - Selling, Rental - renting, Payment - paying, Approval - approving, etc.) it is not surprising to note that a flow of Moment-Intervals often models the structure of a business process with the other class archetypes providing the who, what and where of the process. In business process automation projects, modeling with class archetypes naturally follows from high-level business process modeling and tends to be more effective than purely modeling activity and action flow in something like BPMN or UML activity diagrams. The latter concentrates too much on flow and as a result often suffers from many of the drawbacks of the 1970's practice of designing with flowcharts.

If we add the idea of a flow of related Moment-Interval classes over time by providing associations from a Moment-Interval to PriorMI and NextMI Moment-Interval classes and we splitting the Party, Place, Thing archetype into its three flavors, then repeating the connections in the previous diagram for each flavor produces an archetypal model template that Peter Coad called the Domain Neutral Component [Coad 99].

One important extra detail to note is that the Thing flavor of the Party, Place Thing class archetype typically connects to the MI-Details of a Moment-Interval rather than to the main Moment-Interval.

Domain Neutral Component

Figure 2: Domain Neutral Component (larger detailed image)

My version of the Domain Neutral Component differs in a few small ways from that published by Peter Coad in his Modeling in Color book [Coad 99]. This is due to my preferences developed in using and teaching it over the last ten years or so. The changes are minor, a change in name here, the addition of an attribute there, a change in a multiplicity, and the removal of one or two items that were not earning their keep.

Read more about these changes....

Using the DNC: Building New Object Models

The Domain Neutral Component can really help speed up the building of outline object models of our problem domains.

The way we do this is to begin by looking for some Moment-Intervals in our problem domain. Then we overlay the Domain Neutral Component and start replacing the domain neutral names with names specific to our problem domain. Where we do not need classes from the domain neutral component we drop them out to simplify our model.

A basic lending library is a nice simple example that we can use to illustrate this. First we need our Moment-Intervals. Borrowing a book is the most obvious event or activity at a library but to be able to borrow books we need to first register as a member of the library. So lets use Registration as our first Moment-Interval, and overlay the Domain Neutral Component.

Registration overlaid with the Domain Neutral Component

Figure 3: Registration overlaid with the Domain Neutral Component

Now we start to replace the domain neutral names in the diagram with names from our lending library domain. We consider each of the Party, Place and Thing legs in turn starting with the Party leg.

Party Leg

We need to ask what people and organizations are involved in the Registration Moment-Interval and in what ways they are involved. To keep our example simple we will assume our library only lends to individual people and does not have special memberships for organizations or shared memberships for families.

Someone that registers to become a member of the library enters into a contract with the library. More accurately the contract is between the member and the organization that provides the library service. So we have people playing the role of members and an organization playing the role of library service provider. If we assume that it is this organization that wants the software for which we are building the object model, then the roles being played by that organization can be left as implicit in our model.

This means we can replace the PartyRole class from the Domain Neutral Component with a more specific Member class, the Party class with a more specific Person class, and the PartyDescription class with a PersonDescription class.

Registration with more specific Party classes

Figure 4: Registration with more specific Party classes

If we needed to include the organization offering the library service we would need to duplicate the party leg with a LibraryServiceProvider Role class, an Organization Party class and a OrganizationDescription class. In fact we could have many party roles involve in a Moment-Interval. For now we will assume we only need to model the Person registering as a Member.

Place Leg

Our Registration Moment-Interval enables the borrowing of books from the library. If we ignore, for a short time, the possibility that our library is a mobile or virtual library, we can assume that the library is located in a building of some kind. Therefore, we have some type of building playing the role of being a library in our Registration Moment-Interval. That means we can replace the PlaceRole class in the DNC with a domain specific Library class, the Place class from the DNC with a Building class, and the PlaceDescription class with a BuildingDescription to indicate the kind of building in which the library is located.

Registration with more specific place classes

Figure 5: Registration with more specific place classes

Thing Leg

The act of registering creates a membership account for that person at the library. The Thing class therefore becomes a MembershipAccount class and the ThingDescription becomes an AccountDescription class. The Domain Neutral Component suggests that we might need a role class for our MembershipAccount to encapsulate the attributes and operations that are specific to the way the MembershipAccount class participates in the Registration MomentInterval. Without an obvious name for this role in the domain we give that role class the name AccountInRegistration.

Responsibilities

Now lets consider the typical responsibilities suggested by the class archetypes. We need to compare these suggested responsibilities with the functional requirements for the software. Where there is no need for a particular responsibility we simply omit it. In doing this analysis we frequently find that a class ends up with no responsibilities. In this case we remove the class from the model. This helps us produce the simplest object model that will handle the job well.

The MI-Detail class is responsible for remembering the quantity of a kind of thing involved in the Moment-Interval and for calculating subtotals. Each Registration Moment-Interval only ever opens a single account so we can drop the MI-Detail class from our model connecting the Registration class directly to the AccountInApplication role class.

Although the stereotype tag is a convenient UML mechanism for indicating the archetype of a class, it does hide some very important meaning in a rather plain and simple text label [Coad99]. ... Fortunately the UML standard [OMG] does rather begrudgingly allow us an alternative: color.

The AccountInApplication class is responsible for encapsulating the information and behavior specific to the way a MembershipAccount object participates in a Registration. Unless we have some attributes and operations to place in this class it is redundant and we can drop it form the model too.

Description classes are typically responsible for describing groups of objects that have a set of values in common, for finding members of this group that are available to perform a particular role in a particular moment-interval, and for assessing the performance of the group of objects as a whole.

The AccountDescription class could be responsible for defining the values of different types of membership. Its objects might, for example, be responsible for knowing how many books can be borrowed concurrently by people with the membership accounts it describes. It might restrict the types of books being borrowed so that people holding child membership accounts cannot borrow adult-only books.

On the other hand, if we only have one type of membership at our library we do not need a Description class to distinguish between the different types and we can drop the class from the model. Also we actually have a 1-1 relationship between the Registration class and the MembershipAccount class. A person always registers once to open a membership account. Every membership account needs a registration to create it.

There is a general principle that a 1-1 association between classes offers the opportunity to collapse the two classes at the ends of the association into one class. There may be a good reason for keeping the responsibilities split between two classes but when there is not, the simpler model is preferable. [Coad 97]. Therefore, lets collapse the MembershipAccount class into the Registration class.

Model simplified as client requirements clarified about types of membership accounts

Figure 6: Model simplified as client requirements clarified about types of membership accounts


The PersonDescription class is trying to categorize people. People can be grouped by age range, gender, martial status, ethnic background, nationality, citizenship, and so on. For each categorization we need to add a separate Description class. Description classes often end up as little more than simple sets of enumerated values. Categorization of people can also be a sticky ethical and legal subject. If we discover our library service provider needs no more than basic name and contact information about their members then we can drop the PersonDescription classes altogether.

A similar argument applies to the BuildingDescription class. If there is no requirement to know what type of building a library is located in we can drop that class.

Also if our client is only interested in the buildings containing their libraries and no interest in any other use that is made of the building then we have a 1-1 relationship between our Library class and the Building class and can collapse the two classes into one. When Place and Thing classes are collapsed together with their role classes we tend to leave the result as a Party, Place or Thing class. This reflects that idea that the place or thing has been constructed or purchased for one and only one purpose. Therefore we end up with a single Party, Place, or Thing class we call Library.

Model simplified as client requirements clarified about library buildings

Figure 7: Model simplified as client requirements clarified about library buildings


If we discover that our library service provider has only one library and has no intention of opening another library we end up with a 1-1 relationship between the Library class and the Registration class. If there is only one Library that can be involved in the transaction we can leave that as implicit in our model and remove the Library class.

Also if a person only ever needs to register once at the library to become a member for life then we have a 1-1 association between the Registration class and the Member class and we can collapse the Registration class into the Member class.

We are now left with a very simple two class model with the Person class responsible for uniquely identifying the real world person who holds the membership and the Member class that is responsible for holding the membership information such as late fee balance and membership number. When an application or registration process is very simple like this, the model often reduces in this way.

Model simplified as client requirements clarified about registrations

Figure 8: Model simplified as client requirements clarified about registrations


We can collapse the model even further to a single Member class. This might be appropriate in a web-based system for consumers where the same person can register multiple times and it is not practical or important enough to have a single view of all of a person's dealings with the company.

Obviously this an extreme example and more complex business processes require all or nearly all of the classes in the DNC pattern.

Using the DNC to Review Existing Object Models

Another way to use the Domain Neutral Component is to help review and restructure existing object models.

coloring In Object Models

The basic technique involves 'co louring in' the classes in the model by assigning them to class archetypes and then comparing the result to the Domain Neutral Component. When working with printed diagrams we can literally co lour in the classes using pink, yellow, green and blue highlighter pens. Most modeling tools allow us to set the background color of a model element and the stereotype tag. If the 'UML in co lour' profile is switched on, Borland Together 2006 automatically sets the background color when we select the archetype name in the stereotype property of a class.

The first question of course is given a class what archetype should it be given. Peter Coad suggests asking the following questions in order until you either answer yes or reach the end [Coad 99]

  1. Does the class represent a moment or interval of time that we need to track for business or legal reasons?
    Yes - then color it pink, it belongs to the Moment-Interval class archetype

  2. Does the class represent a role being played by a party (person or organization), place or thing?
    Yes - then color it yellow, it belongs to the Role class archetype

  3. Does the class represent a catalog-entry like description?
    Yes - then color it blue, it belongs to the Description class archetype

  4. Color the class green, it belongs to the Party/Place/Thing class archetype

Lets illustrate this with an example using the following simplified object model of flights and airports as an example


Model to be reviewed

Figure 9: Model to be reviewed

We take each class in turn and ask the four questions in turn until we have an answer.

  • Person
    A person is not a moment or interval of time that we are interested in for business or legal reasons. Yes, a person's lifetime could be a moment or interval of time that might be of interest to some software systems but the person himself or herself is not. For the purposes of our object model we can state that person is not a role played by someone, some place or some thing. A person is always a person. People are unique and that uniqueness enables them to be identified individually. Changes of identity such as those caused by FBI-like witness protection programs or illegal immigration are the exception to the rule. Thankfully most of us can conveniently ignore such rare exceptions in our work. People are not catalog-entry-like descriptions. They are not a categorization of a set of objects. Therefore, we conclude that the Person class belongs to the Party, Place or Thing archetype and is green in color.

  • Pilot
    A pilot is not a moment or interval of time that we are interested in for business or legal reasons. A pilot is not an event or activity. Flying is an activity and becoming a pilot is an event but the pilot himself is neither. However, a pilot is a role played by a Party. It is a way of participating in the activity of flying. Therefore the Pilot class belongs to the Role archetype is yellow in color.

  • Passenger
    For the same reasons as a pilot, a passenger are not a moment or interval of time that we are interested in for business or legal reasons. A passenger is a way of participating in an activity or event and that means the Passenger class belongs to the yellow Role archetype.

  • Flight
    A flight is the interval of time between an airplane taking off and landing again. The flight class is a Moment-Interval and we can color it pink.

  • Seat Reservation
    The reservation of a seat on a flight is an event; it is a moment in time of interest for business reasons, a business transaction, an interaction between the travel agent and the traveler. The SeatReservation class belongs, therefore, to the Moment-Interval class archetype.

  • Airport
    An airport is not a moment or interval of time that we are interested in for business or legal reasons. The interval of time that an airport is open for business might be of interest but an airport itself is not a moment or interval of time. Is an airport a role played by a party, place or thing? In a state planning system, it could be argued that an airport is a role played by a particular parcel of land. In our problem domain, however, an airport is a place where our flights begin and end. The airport is not a catalog-entry-like description. It is a place and the Airport class belongs to the Party, Place or Thing archetype.


A 'colored in' version of the example object model

Figure 10: A 'colored in' version of the example object model


Comparing with the DNC

Now that we have 'colored in' our object model we play 'spot the difference' with the Domain Neutral Component.

Challenge Multi-colored Inheritance

An immediately obvious difference is the inheritance relationship between Person and its subclasses Pilot and Passenger. In the DNC, Role classes are associated to their role-player class; they do not inherit from it.

Inheritance is an extension mechanism. An object of a subclass is the same kind of thing as an object of its superclass but our object model has the Passenger and Pilot as different kinds of things, different archetypes, from their Person superclass. Why is this a problem? Imagine what happens if one of our pilots wants to be a passenger on a flight he or she is not actually piloting. We have three options, all of them bad:

  • The Pilot object representing our pilot needs to transmute into a Passenger object so that the pilot can reserve a seat. Next time the pilot pilots a flight the object has to transmute back again to being an object of the Pilot class. Ouch!!!
  • We create both a Pilot object and a Passenger object duplicating the person information and essentially having two Person objects in our system for a single real person. Yuck!!!
  • We add the ability for Pilot's to make seat reservations. We duplicate this responsibility in both the Passenger and Pilot classes. Nasty!!!

The Domain Neutral Component suggests we relate the Person class to its role classes using a simple association. This gives our Person objects the ability to play neither, either or both of the Passenger and Pilot roles over time without the need for objects to change from one class to another or duplication of information or responsibility. We would probably want to check that a pilot on a flight has not booked a passenger seat for himself on the same flight but checking for conflicts in role being played is an archetypal responsibility of the role-player class so that fits very nicely into our overall pattern.

Another conclusion we can draw from this is that we need to challenge multi-colored inheritance relationships; inheritance relationships where the class on one end belongs to a different archetype to the class on the other end.

Look for Missing Place and Thing Roles

The Domain Neutral Component suggests that there may be a need for Role classes between Moment-Interval classes and Party, Place, or Thing classes. Our colored model has the Flight Moment-Interval class associated directly to a Place Airport class. Are we missing a role class in between?

Each object of the Flight class is related to two objects of the Airport class; the airport from which the plane takes off and the airport at which it subsequently lands. There are therefore two different roles being played by the airport objects; those of departure airport and arrival airport. If there are differences in the responsibilities of these two roles then we might want to add classes to model these two Roles.

The airport class is responsible for allocating runways for a flight to take off from and land on. This presumably works differently depending on whether the flight is arriving or departing. You certainly do not want to be taking off from a runway when another plane is about to land on it. We can split the responsibility between the two roles making the departure airport role responsible for allocating a runway for a flight to take of from, and making the arrival airport role responsible for allocating a runway for a flight to land on. The roles can also split the handling of performance assessments such as counting the number and percentage of flights taking off on time and landing on time; a nice partitioning of responsibilities.

Restructured object model

Figure 11: Restructured object model

In general, if there is behavior specific to the way a Party, Place, or Thing object participates in a Moment-Interval then it may be useful to separate that behavior out into a Role class played by the a Party, Place, or Thing class.

Of course, we might find that we genuinely do not need the level of partitioning or specificity provided by a role class and the simpler model does the job perfectly well without the additional complexity of another class. Classes of the Party archetype nearly always play multiple different roles in a system. Place classes often play multiple roles but Thing classes tend not to play multiple roles very often. This is because Things are normally created and purchased to serve one purpose and one purpose only. Therefore a Thing is most likely to only perform one role and the responsibilities of that role can be collapsed into the Thing class itself.

So, in conclusion, challenge associations from Moment-Interval (and Moment-Interval Detail) classes directly to Party, Place, or Thing classes and ask if there should be a yellow Role class between the pink Moment-Interval and green Party, Place, or Thing class.

Summary

The Domain Neutral Component is an archetypal pattern for object models.

We can rapidly build robust, flexible object models by identifying Moment-Intervals in our problem domain, overlaying the Domain Neutral Component, replacing the domain neutral names with domain specific names and removing responsibilities and classes where we do not need that level of specificity.

Existing object models can be improved by assigning their classes to class archetypes and comparing the result with the Domain Neutral Component.

In particular, we challenge any inheritance relationships that have classes belonging to different archetypes participating in the relationship. We also challenge associations directly between Moment-Interval classes and Party, Place, or Thing classes, asking if a Role class is needed in between.

Art is the imposing of a pattern on experience, and our aesthetic enjoyment is recognition of the pattern
Alfred North Whitehead

The Moment-Interval Class Archetype
Modeling in color defines four archetypes. The first of these, the Moment-Interval class archetype, 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...

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...

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...

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...

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...

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...

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...
Follow me on Twitter...