CSC/ECE 517 Fall 2010/ch6 6h mf

Domain Models

Introduction

The domain model is an object model that encapsulates the rules, logic, and data associated with the problem domain. The purpose of domain modelling is to separate the concern of domain-specific problem solving from other concerns like the user interface and persistent storage.

A number of different terms are used to refer to the domain model and related concepts. These include Domain Object Model (DOM), domain layer, business layer, business logic, business logic layer (BLL), business tier, and logic tier. Many of these terms are used when describing multi-tier architectures. The canonical example is the three-tier architecture composed of the a presentation tier, logic tier, and data tier. The presentation tier is responsible for the user interface. The logic tier (domain model) is responsible for solving problems in the specific domain of the application (often a business domain, hence the term business logic). The data tier is responsible for storing and retrieving information, typically to and from a database.

The three-tier architecture illustrates how domain modelling helps achieve separation of concerns. The presentation tier could be implemented in a number of different ways. For example, it could be a command-line interface (CLI), a graphical user interface (GUI), or a web-based interface. It might be desirable to support several different types of user interfaces. However, the type of interface and its implementation is largely independent from the problem domain. Separating the behaviour and data of the user interface from the behaviour and data of domain model enables developers to reuse domain-specific code while implementing various user interfaces. In addition, weak coupling between the user interface and domain model allows the domain-specific code to vary with negligible effect on the user interface code.

Domain objects represent real world entities, both tangible and intangible, encountered in the problem domain. For example, consider the Spring framework PetClinic sample application, which is a simple example of a three-tier architecture. The essential elements of the domain model are represented in UML in the figure below. The domain objects include Person, Vet, Owner, Pet, and Visit. Visit is an example of an intangible entity, in other words an abstract concept, that is part of the problem domain. Contrast these domain objects with GUI objects like buttons and text fields which are not relevant to the problem domain (in this case, operating a veterinary clinic).

In addition to representing real world entities (domain objects), domain models also represent the relationships between these entities. For example, an Owner has an is-a relationship with a Person and a has-a relationship with a Pet. These relationships are of little relevance to the user interface. In the database, some relationships, particularly has-a relationships, must be represented. However, others, like is-a relationships, typically do not. For example, the base class Person, an important abstraction in the domain model, does not even appear in the PetClinic database. This is because the database is primarily concerned with storing and retrieving application data. Abstractions are relevant to the domain model, but the database only needs to represent concrete data.

An example of business logic

The PetClinic example is useful for understanding domain objects and the relationships between them, but another important aspect of the domain model is that it represents rules and logic that are specific to the problem domain. The following example of some business logic that could be represented in a domain model appears in The Mythical Business Layer.

When a Sale is Cleared, only Managers with Void Approval and Executives may issue a Cancellation Request. If the Propagation Status for the Transferable Receivable is not Pending and the Expense Allocation Type is Reversible, the Cancellation Request is issued for Processing; otherwise, it is issued for Approval.

This example dictates the circumstances of the cancellation of an item (TransferableReceivable) from a sale. An example of a rule contained in the statement is that "only Managers with Void Approval... may issue a Cancellation Request." Potential domain objects are Sale, Manager, Executive, CancellationRequest, and TransferableReceivable. An example of a behaviour that a Manager may exhibit is issueACancellationRequest(). An example of domain-specific data is hasVoidApproval which is an attribute of a Manager.

Possible class diagrams for the domain objects are presented in UML below. Has-a relationships are represented through attributes. Is-a relationships are not explored. It would stand to reason that Manager and Executive both inherit from an Employee class, but this is not modelled below.

Sale

items : TransferableReceivable[]

clear()

Manager

hasVoidApproval : Boolean

issueACancellationRequest(item : TransferableReceivable) : CancellationRequest

Executive

issueACancellationRequest(item : TransferableReceivable) : CancellationRequest

CancellationRequest

item : TransferableReceivable

issueForProcessing() issueForApproval()

TransferableReceivable

propagationStatus : Enum expenseAllocationType : Enum

Notice how these class diagrams encapsulate entities (domain objects), data (attributes), and behaviour (methods) which are relevant and specific to the business problem that the application solves, namely cancelling items from a sale which has been cleared. This domain model does not address how information is presented to the user or how information is made persistent. These are issues which are not specific to the problem domain and are therefore addressed outside the domain model.

Anemic Domain Models

When domain models fail to encapsulate behavior as well as entities and data, the Anemic Domain Model anti-pattern results. One symptom is the presence of a domain layer and a service layer which provides methods which operate on the objects in the domain model. Adding a service layer can reduce code duplication, especially if there are many different domain objects with similar behaviours. The domain model becomes anemic when the service layer unnecessarily subsumes behaviours from the domain model.