The Domain Layer

The domain layer is also called the business layer. It encapsulates business or domain logic and data. This layer might be deployed as an application server.

Domain Model

During the analysis phase of development a domain model is created to represent the business environment of the application. During the design phase, details are added to the domain model and it becomes the domain layer of the application.

For example, here is a sketch of a model of a video rental store business:

As we can see, there are many classes in the domain layer. This can lead to complex dependencies between the presentation layer and the domain layer. These dependencies can be simplified using the Facade Pattern.

Transaction Script

A non-object-oriented approach is to implement the main domain transactions as static methods or scripts:

class VideoRentalTransactionScripts {
static void rent(int recordingID, int customerID) { ... }
static void return(int recordingID, int customerID) { ... }
// etc.
}

Of course transaction scripts can be very complicated. If business rules change or if there are changes to the database, then we may need to completely re-write our scripts.

On the other hand, transaction scripts are completely procedural. There are no objects involved.

Table Module

Instead of having a single object in the domain layer represent a single row in a database table, a table module is a single object that represents an entire table.

For example, we might create a table module from a row set returned by a table gateway. Unlike a row set, a table module also contains business logic.