Layers

Presentation: provision of services, displayer of information (e.g. in Windows or HTML,handling user requests), HTTP requests, command-line invocations, batch API.

Domain: Logic that is the real point of the system.

Data Source: Communication with databases, messaging systems, transaction managers, other packages.

Organizing Domain Logic

Recall that patterns represent general design choices. Patterns are not specific implementation choices.

Three primary patterns:

Transaction Script

Domain Model

Table Module

Most use cases in web and enterprise applications are "CRUD" (create, read, update, delete). Nevertheless the applications can involve increasingly complex logic and interactions with other services.

Transaction Script

A procedure that takes input from the presentation layer, processes input, accesses relevant information from the database, using some kind of Data Gateway, manipulates the information and returns results possibly with additional presentation information.

Can be thought of as one script for each action or transaction that the system is required to do.

Advantage: simple procedural model that is easy to understand

                   works well with a simple data source layer: document key-value DBs like CouchDB

                  transaction boundaries are obvious in that the transaction finishes when the transaction scripts finishes.

Disadvantage: Transaction scripts become more complicated as the complexity of the domain logic increases-

                       significant duplication of code can occur.

Domain Model

The Domain Model uses a full object-oriented approach to represent the domain logic.

It can be harder to see the behavior of a Domain Model and how it relates to the underlying data source.

Objects in the domain model interact to accomplish the desire action.

Explicit connection to the Data Source layer is omitted in a domain model design. Instead, objects may be considered as active records or in more complicated situations may be stored/retrieved using a data mapper.

Active Record

An active record is essentially an object, with domain logic, that implements database create/read/update/delete operations.

Advantage: it is applicable for simple applications of the domain model

                           where there is roughly one domain class per database table or document,

                           and where the domain objects have only moderate complex business logic.

Disadvantage: breaks down as the domain logic becomes more complex

                            the pattern doesn't work well with inheritance and where domain logic is factored into smaller

                           classes.

Data Mapper

A data mapper is used to isolate the domain model from the database completely.

    A data mapper handles things such as classes that use multiple documents or tables in the database, classes with inheritance, and connecting together objects once they've been loaded.

    It is most complicated of the database mapping architectures

    tools exist to help Object/Relational(O/R) mapping. e.g. Hibernate.

Table Module

The table module pattern is somewhat in between Transaction Script and Domain Model pattern:

    maintains an array of objects

   each table module is initialized with data from a Record Set, and then the domain logic operates on that data

   it is used by a number of platforms, particularly Microsoft's COM and.NET.

Making A choice

Your choice depends on your judgement concerning how complex the domain logic is intending to be. This is generally by experience and careful analysis of requirements.

   Table module works around Record Set which is supported by tools like .NET or Visual Studio.

   Hard to refactor from one pattern to another.

    Three patterns are not mutually exclusive. They can be combined.

Service Layer

A common approach in handling domain logic is to split the domain layer in two.

A service layer is placed over an underlying Domain Model or Table Module design

    A transaction script design typically isn't complex enough to warrant a service layer-

    you may end up having a script per service layer method,

The presentation logic interacts with the domain logic purely through the service layer which is an API for the application. The operations provides are typically derived from the use case model and user interface design.

The service layer is a good place to put security checks and transactional wrappers; things that are common across all service.

Whether you use a thin (API only of facade) or a think (with application logic as opposed to domain logic), service layer is a design choice that depends a lot on the other patterns that you are using.