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:
- 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.
- the number attribute of
the Moment-Interval class archetype, I rename to referenceNumber. This conveys
purpose of this attribute far better, especially as many reference numbers are more accurately modeled
as character strings instead of a numeric type.
- 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.
- 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.
- 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.
- 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.
- 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.
- For the same reason as 7, I rename the qty attribute in the MI-Detail,
spelling it out in full as quantity.
- 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
- Instead of serialNumber,
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.
- 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
- 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,
- 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.