Day 9 – Enterprise Application Architecture Patterns – Domain Logic Patterns


1. Transaction scripts

1) Call the database:

Transaction scripts compose all logic into a single process in which the database is invoked directly or only through a simple database store.

2) script processing:

Each transaction has its own transaction script, although common subtasks between transactions can be decomposed into multiple subroutines.

3) Operating mechanism:

A. Transaction scripts should be placed in classes that are independent of other classes that process the presentation layer and the data source layer. There are two ways to organize transaction scripts into classes:

A. Put several transaction scripts in one class, each class organizes related transaction scripts around a topic;

B. Using Command mode, each transaction script corresponds to a class (command)

4) Use time:

Simple scenarios of business logic (while cautiously extracting common subroutines to reduce code redundancy) require domain models when business is complex

5) Advantages:

When the problem itself is simple, using transaction scripts can speed up development and run faster.

6) Examples:

If there are the following requirements:
Day 9 - Enterprise Application Architecture Patterns - Domain Logic Patterns
The database design is as follows:
Day 9 - Enterprise Application Architecture Patterns - Domain Logic Patterns
The Revenue Recognition table refers to the Id of the Control table as the foreign key. According to requirements and database design, transaction script class diagram is designed as follows:
Day 9 - Enterprise Application Architecture Patterns - Domain Logic Patterns

Here, Gateway is the database access register and Recognition Services is the transaction script class. Calculate Revenue Recognition method is used to calculate and save the required entry information (contract number, time, fee amount), and Recognize Revenue is used to query the charged information according to contract number and specified date. The application only needs to call these two methods individually.

2. Domain Model

1) Operation mechanism

The difference between domain model and database model is that domain model is a complex network composed of interconnected fine-grained objects with mixed data and processing process, multi-valued attributes and complex association network, and uses inheritance, strategy and design patterns.

A common problem with domain logic: Domain objects are too bulky and may generate redundant code

Database mapping: Simple domain models can use activity records, while complex domain models need to use data mappers.

Domain models should use fine-grained objects with fine-grained interfaces.

2) Opportunity

When business rules are complex and changeable, involving verification, calculation and derivation.

Database interaction: preferred data mapper

3) Examples:

For the above requirements, the design class diagram is as follows:
Day 9 - Enterprise Application Architecture Patterns - Domain Logic Patterns    

As you can see, the policy mode is used here.

3. table module

The table module organizes domain logic with a class corresponding to a table in the database, and uses a single class instance to contain various operating procedures for the data.

The difference between the table module and the domain logic is that if there are multiple orders, the domain model has one object for each order, while the table module only uses one object to process all orders (the table module has no identifier to identify the entity object it represents).

1) Operation mechanism

Strength: Allows you to encapsulate data and behavior, while taking full advantage of relational databases

2) Opportunity

Use when accessing table data using recordset (table modules depend heavily on data organized in table format)

3) Examples:

The design class diagram is as follows:
Day 9 - Enterprise Application Architecture Patterns - Domain Logic Patterns  

4. service level

The service layer defines the boundaries of the application and the set of available operations that can be seen from the point of view of the interface client layer. It encapsulates the application’s business logic, transaction control and response coordination in its operation implementation.

1) Operation mechanism

Business Logic Classification: Domain Logic and Application Logic

Two basic implementations:

  • Domain Appearance Method:

The service layer is implemented as a thin collection of facades on top of the domain model (the class responsible for implementing the facade does not contain any business logic, and all business logic is implemented by the domain model)

  • Operational scripting method:

The service layer consists of a relatively complex set of classes that directly implement application logic, but delegate domain logic to encapsulated domain object classes.

The service layer interface is coarse-grained and can be called remotely if necessary (adding a remote appearance to the service layer or directly enabling the service layer to implement the remote interface)

2) Opportunity

Service layer advantages:

It defines a common set of application operations that can be used by various customers, and the service layer coordinates the application response in each operation.

When the business logic has multiple customers, or multiple transactional resources in the use case response, the service layer is required

Recommended Today Application of regular expression

1. Balanced group / recursive matching (?’ Group ‘), which is called the corresponding content of group, and counts it on the stack;(?’- Group ‘), and count the corresponding content named group out of the stack(?!) Zero width negative look ahead assertion. Since there is no suffix expression, attempts to match always failRegular example:,{0,1}”5″:\[[^\[\]]*(((?’Open’\[)[^\[\]]*)+((?’-Open’\])[^\[\]]*)+)*(?(Open)(?!))\],{0,1} Test […]