Domain Modeling – Why Bother?
In my last blog, "Understanding the As-Is Process Model", I talked about techniques for identifying, modeling, and communicating the analyst’s understanding the business processes being considered for automation. In this blog I’ll talk about how to add "meat" on the process infrastructure to deliver a workable solution.
The domain model is created in order to represent the objects (vocabulary and key concepts) of the problem domain. The domain model also identifies the relationships among all the entities within the scope of the problem domain, and commonly identifies their attributes. The domain model provides a structural view of the domain that can be complemented by other dynamic views, such as Use Case models. The objects in the domain model provide the inputs to, and the output of, the business processes (collections of activities) under consideration. In investigative terms, the objects in the domain model provide the facts of the case… the evidence of process. You’ll never fully understand the processes unless you fully understand the objects involved in the processes.
An important benefit of a domain model is that it describes and constrains the scope of the problem domain. It is especially helpful as a communication tool and a focusing point both amongst the different members of the business team as well as between the technical and business teams.
Objects are defined as the people or things described in the processes being studied. An effective method for identifying objects is to identify the nouns in a given process. By studying the nouns and associated verbs, you can identify objects and associated services. A sentence with a subject, verb, and direct object indicates two likely business objects—the subject and the direct object. If the direct object is being acted upon by the system, it is the most likely candidate object. True objects usually contain more than one attribute.
Some processes might not explicitly contain objects, even though objects are necessary to perform the required business activities. Examples of such objects include structures, systems, devices, things, and events. To identify missing objects, think about the business scenarios in terms of required information and behavior that is not associated with an object.
To identify the attributes of an object, the analyst should consider each business object and attempt to answer the following questions:
- How is the object described in general and as part of this solution?
- How is the object described in the context of this solution’s responsibilities?
- What information does the object contain?
- What information should the object maintain over time?
- What are the states in which the object can exist?
Each attribute is generally identified with an object. You need to clearly label each attribute to avoid confusion with other attributes. In addition, record the structure or type of the attribute, such as text or number.
So why bother modeling the domain? If we as analysts don’t fully understand and communicate the domain model to stakeholders, who will? Invariably it will fall to the developers or database architects. Unfortunately, such scenario is very common and often leads to a technically skewed solution. Technicians cannot help but form the conceptual solution in terms of technical implementation. It soon becomes the old "solution in search of a problem" syndrome.
Analysts are supposed to bridge the business domain with the technical team. The better we can communicate to both constituencies, the more likely the solution will actually be delivered successfully.