As understand it, the domain model is "sort of" a differnet view of the business model.
The business model is used to gain insight into the wider scope of the subject system and its use within the organization. At this level, we see the business process elements and the business organizational elements that "have some visibility" of the system.
The business model is essentially
behavioral even though it contains structural elements - we see organizational structures and high level business processes, and perhaps some actual roles played by actors that are particularly pertinent.
The domain model is the first cut at the structural composition of the organization. However its scope is bounded securely by the "system" under discussion.
Lets see if we can generate an example - say a retail wine distributor developing an online store
We may need to model the business to see how the proposed web site will "fit" into the business.
The company organisations that are involved with the system somehow are:
The
warehouse who will be dispaching the wine to customers.
The
accounts department who will have to be notified of accounts receivable items (for credit card sales), inventory changes (for restocking and licence/excise matters).
The
management will want measurement of sales made through the site.
The
marketing department may want measurment of the types of sales made so they can plan what to push etc.
The "
art" department may need to be involved in keeping the page "attractive"
The
IT department (never forget this one and never leave it out as being too obvious) who have to run and support the site.
There are communicates and subscribes associations between these structures and the "system"
We use this model as a checklist with the business to make sure that no-one is forgotten in the requirements and analysis stages.
Now from that model we can start to derive the set of business objects that are salient to the system:
Order (we may even see at this point that an order appears to have states of "Open", "Authorised" and "Filled".)
Customer (aka "Deliver To")
etc etc
No really detailed fleshing out of these elements is needed - they act as placeholders for discussions with the business, say as in "Do you want to keep records on every customer that buys through the wine site? Lets talk this through and see what impact it will have - and what issues are raised."
Sometimes you need a business model, sometimes not.
Many times I see analysts attempting to avoid domain models - again, they are not really "compulsory" but add a great deal of value, at the least the provide a checklist that can be used to validate the rest of the requirements view and the analysis view.
B
