Organizing Domain Logic Into 3 Types of Patterns

Organizing Domain Logic

Domain Logic != Persistence Logic

Domain Logic = Calculations, Server Side Validations, 

Persistence Logic = Filtering, Selecting and Projecting, Saving, Upgrading, Adding, Deleting the Data inside the Data Table

There are many different ways of organizing domain logic in Business Components that encapsulate calculations, validations, and other logic that drives the central functionality of an application.

Fowler defines three architectural patterns (here listed in increasing order of complexity) that designers use to organize domain logic. 

Transaction Script.

This pattern involves creating methods in one or a few Business Components (classes) that map directly to the business functionality that the application requires. 

The body of each method then executes the logic, often starting a transaction at the beginning and committing it at the end.

This technique is often the most intuitive but is not as flexible as other techniques and does not lead to code reuse. 

This pattern tends to view the application as a series of transactions.

======================================

Table Module

This pattern involves creating a Business Class for Entity/Table used in the Application. It contains all Domain logic Methods related to one or more Rows in the Table.

This pattern takes advantage of the ADO.NET DataSet and is a good mid-way point between the other two. 

This pattern tends to view the application as sets of tabular data.

Domain Model

Like the Table Module, this pattern involves creating Business Class for each Entity/Table in a system, however, here each Business Obj represents one Entity/Table Row rather than only having one Business Object for Multiple entities/Table Rows. 

Here also, the logic for any particular operation is split across the objects rather than being contained in a single method. Orchestration is done at the Application Service Level.

This is a more fully object-oriented approach. This pattern tends to view the application as a set of interrelated objects.