• Transaction Script ( Transaction Script )
• Domain Model
• Table Module
• Service Layer (Service Level)

Transaction Script ( Transaction Script )

Transaction Script Design Pattern

Transaction Script Description

Organizes business logic into procedures that each manage its request.

Most business applications can be represented as a set of transactions. Some of them choose the data, some - change. Each user and system interaction contains a specific set of actions. In some cases, this may simply be a data output from the database. In other cases, these actions can contain many calculations and checks.

The Transaction Script pattern organizes all this logic into one procedure, working in the database directly or through a thin wrapper. Each transaction has its own Transaction Script, although general subtasks can be broken down into procedures.

Domain Model

Domain Model Design Pattern

Domain Model Description

Domain object model that combines data and behavior.

Unfortunately, the business logic of an application can be very complex. Rules and logic describe a variety of cases and behavior modifications. To handle all this complex logic and designed objects. The Domain Model pattern (domain definition model) forms a network of interconnected objects, in which each object is a separate significant entity: it can be as big as a corporation or as small as the line from the order form.

Table Module

Design Pattern Table Module

Table Module Description

One entity processes all business logic for all rows in a database table or view.

One of the fundamental principles in OOP is a combination of data and methods for processing this data. The traditional object-oriented approach is based on objects with consistency, as, for example, in the Domain Model pattern. Thus, if there is a class Employee, any instance of this class corresponds to a specific employee. This structure works well because, having a connection, you can perform operations, use relationships, and collect employee data

One of the problems in the Domain Model pattern is the interface to the database. This approach refers to the database as if it were a mad aunt locked in an attic with whom no one wants to talk to. Often, you have to try hard to write or read data from a database, transforming it between two views.

The Table Module pattern divides the logic of the definition domain (domain) into separate classes for each table in the database and one instance of the class contains various procedures that work with data. The main difference from the Domain Model is that if there are several orders, the Domain Model will create its own object for each of the orders, and the Table Module will manage all the orders with one object.

Service Layer (Service Level)

Service Layer Design Pattern

Service Layer Description

Defines the boundary between the application and the services layer, which forms the set of available operations and controls the application's response in each operation.

Business applications typically need different interfaces to the data they store and the logic they implement: data loaders, user interfaces, integration gateways, and more. Contrary to various objectives, these interfaces often need to interact with an application to access and control its data and the execution of logic. These interactions can be complex, using transactions on multiple resources and managing multiple responses to an action. Programming the interaction logic for each interface will cause more duplication.

The Service Layer pattern defines for the application a boundary and a set of allowed operations from the point of view of client interactions with it. It encapsulates the business logic of the application, managing transactions and managing responses in the implementation of these operations.