CSC/ECE 517 Fall 2010/ch6 6h cb

Introduction

Although they share the same acronym, the Document Object Model discussed in the previous chapter and the Domain Object Model (DOM) discussed here have very little in common. Throughout the chapter I may abbreviate the Domain Object Model as DM (since it is also referred to as the Domain Model) so that it is not confused with the more common use of DOM as a Document Object Model.

A Domain Model is a tool used to translate business logic into a visual representation. This visual representation includes all relevant relationships and data so that customers, developers, experts and non-experts can all understand and contribute to a system's design. It can also be used to verify a particular problem domain or system architecture in a consistent format so that everyone fully understands the design.

What is a Domain Model?

To help define a Domain Model we’ll use the example of an online store which includes a shopping cart, items to purchase, a customer, etc. The DM for such an abstraction would look similar to the following

Image:Simple_DOM

At first glance, the structure of a DM looks very much like a flow diagram, UML diagram, or database map with slight variations on each of these. The big blocks in the diagram represent the Business Objects of the model. These objects typically represent real world objects and are modeled accordingly[7].

For instance, the shopping cart in the example above is a business object. Each business object in a DM holds certain variables and attributes that pertain directly to that object. A shopping cart may contain a customer number, a list of items, and a total price. In addition to holding data, these objects can also perform operations. In fact, a domain model where objects do not contain any logic is called an Anemic Domain Model[6]. Most objects, however, do contain business logic, such as an AddToCart method for the shopping cart object.

So thus far a DM may not seem very different from a UML diagram or database map diagram. However, what it can represent that the other two cannot is a process or series of events. So then beyond simply defining the relationships between objects, such as a shopping cart contains items, a DM can specify that a customer must add items to the shopping cart before being able to check out, for instance. This can be very helpful in complex domains such as a government approval process where an item might need to be approved by a dozen different people in a particular order and routed appropriately if denied.

When to use a Domain Model

The two primary development cycles that Domain Models are used are Domain Driven Development (DDD) and Feature Driven Development (FDD).

Domain Driven Development

The first, Domain Driven Development, concentrates on tackling complex problems by leaning on the expertise of the domain in which the problem exists[5]. In this case a Domain Model can be very useful in determining if all parties in a project fully understand the domain and how each piece works together in the system. It is important, however, that all pieces of the DM be written in a “ubiquitous language” that is common among experts in the field.

Feature Driven Development

Feature Driven Development, uses a very communicative relationship between developers and customers to iteratively develop and refine features requested by the customer[4]. The DM is an important piece of each iteration of the cycle and is one of the first things that is agreed upon by both parties. As it works in DDD, the Domain Model serves as proof that both sides agree and understand the problem domain before any design or development work begins. This is especially important for complex systems.

Conclusion

In all honesty, creating a well done domain object model is a time consuming and difficult task. However, it is one of the few ways that a combination of customers, system experts, and developers can agree and understand the interaction of components of a system from the very beginning of the development cycle. By properly using a domain object model as part of the design process a team can save themselves confusion, misunderstanding, and the most precious commodity of all, time.