Peter Coad first presented the Domain Neutral Component as part of his 'modeling in color' technique in 1999, in the book Java Modeling in Color with UML. 

Figure 1: The Domain Neutral Component (click on it for more detailed view).

While teaching, applying, and thinking about it for over a decade, I slowly incorporated a number of very small modifications that I now use all of the time. They are:

1. typical operations of the Moment-Interval class archetype that had a prefix of mi_, I rename to have an MI suffix instead. For example, I rename mi_assessWRTPrior() to assessWRTPriorMI(). Not only is this consistent with Java and UML naming conventions, and closer to C# naming conventions (except for the case of the first letter), I find it reads better too.
   
   
2. the number attribute of the Moment-Interval class archetype, I rename to referenceNumber. This conveys the purpose of this attribute far better, especially as many reference numbers are more accurately modeled as character strings instead of a numeric type.
   
   
3. I add a purpose attribute to the Moment-Interval class archetype. The party, place, and thing legs in the DNC answer the who, where and with what of the Moment-Interval, purpose is used to indicate why; why this loan, why this meeting, why this sale, why this cancellation? Sometimes encoded as an enumeration, but as frequently just a word or sentence in a character string.
   
   
4. I drop the planned-actual association linking the Moment-Interval to itself. While I recognize the intent and potential usefulness of this association, I have not used it enough in practice to warrent it being present on the DNC. I leave this as a subordinate pattern similar to the subsequent role pattern. As a consequence, I also drop the mi_comparePlanvsActual() operation from the Moment-Interval class archetype.
   
   
5. I drop the plug-in point on the Moment-Interval. I have not ever found it used in practice. As a consequence, I also drop the makeMomentInterval() operation from the Moment-Interval class archetype.
   
   
6. I drop the recalcTotal()  operation from the Moment-Interval class archetype. In practice, I find the calcTotal() operation enough of a reminder to consider what totals should be calculated and when. In addition, the idea that calcTotal() caches a total when first called returning the cached value on subsequent calls, with recalcTotal() forcing a recalculation  of the cached value has caused me as many problems in transactional systems as it solves.
   
   
7. the calcTotal() operation I spell out in full as calculateTotal().  I see no value in the abbreviation given the length of the names of other operations in the same class archetype. I do the same for the equivalent operation in the MI-Detail.
   
   
8. For the same reason as 7, I rename the qty attribute in the MI-Detail, spelling it out in full as quantity.
   
   
9. I make the association between the MI-Detail and Thing Role a many to one association rather than a many to many. I find in practice, it is more typical to require a MI-Detail object per thing involved in a Moment-Interval, than to have a single MI-Detail for multiple things  involved in that Moment-Interval.
   
   
10. Instead of serialNumber,  I have an identityNumber attribute in the Party, Place, Thing class archetype. Serial numbers only apply to things, and it is not generally appreciated if you imply that people are stamped with serial numbers.
    
    
11. the two static operations I name the same in each class archetype as listInstances() and assessAcrossInstances(). They provide the same services regardless of archetype and the naming them according to archetype implies they do something subtly different in each case.
    
    
12. I drop the plug-in point on the description class and related assessWithPlugInElseDefault() operation. While I find this is a typical pattern in practice, non-technical people find it a hard concept to get their heads round at first. I generally introduce this later alongside ideas like subsequent roles, etc.
    
    
13. I have not done so yet, but I have toyed with the idea of adding an atTheTimeValue attribute to the Moment-Interval class archetype. I have almost always had to either snapshot values from other associated class archetypes in Moment-Intervals or version the value inside the associated class archetype - something I generally refer to as handling historic values.
    
    

Given the length of time since the DNC was first proposed, it has stood the test of time very well indeed and continues to prove a most effective tool in my tool box.