(some fragments from some of the writing I'd done for a modeling/architecture book. I'll *maybe* post some more of these)
Why is it domain neutral?
Let's look again at what a moment-interval is. It's a moment or interval of time when the business interacts with a party, place and thing, and the business needs to track or do something about the interaction. We also said another word for this could be "transaction" or "event" but that these are very overloaded terms and so we don't use them.
Instead we simply call it what it is. A moment or interval of time that we need to remember. (more...)
We also said that moment-intervals have a previous and a next moment-interval, such as a Reservation and then a Rental in the video rental domain, and that moment-intervals line up in a previous-next chain that represents the sequence of interactions that must be remembered in that particular business.
So, why is the ADS domain neutral or why does this apply again and again across different domains.
Well, in any business area there is a series of interactions between the business and party/place/things that results in whatever this business area does or produces. The business needs to keep track of these interactions. The duration of an interaction varies from brief moments to longer intervals, days or longer. For a particular business the same sequence of interactions is used again and again - to produce whatever this business area does - and we model this as a chain of previous-next moment-intervals. Each of these moment-intervals is associated with a party, a place and a thing, i.e. the party, place and thing the business interacts with for that moment-interval. We record in the Moment-Interval and the associated Party, Place and Thing, the information the business needs to remember about the interaction.
All businesses have their own sequence of interactions, which we model as a chain of Moment-Intervals associated with Party, Place and Thing. We can therefore apply the archetypal domain shape in all businesses (domains).
This treatment boils analysis/requirements/modeling down to three questions.
What are the Party, Places and Things the business interacts with?
What are the interactions that need to be remembered?
What is the sequence of the remembered interactions?
(later...)
We know that the business has a process to handle each of its interactions and we may need to keep a record of some aspects of that process. However, processes change far more often than the interactions (and often as a direct result of a new information system). So, recording information about the process leads us down the slippery slope of changing requirements.
(writers note: This is VERY insightful. The process (relatively) is more volatile. The things involved in it are less volatile. It is similar to coding use case interactions as a controller class. You are hardwiring the very thing that changes the most. A good model captures the things involved in a domain and their relationships. Functions are then free to have those things collaborate in all sorts of different ways and to have those ways change.)
We want our model to be stable and the way we do this is by ensuring it (at least initially) reflects just the interactions the business performs and the parties, places and things it performs those interactions with.
(co-authored by Phil Bradley, Jeff De Luca, Paul Szego)
