Business logic architecture model (transaction script, table module, activity record, Domain Model)

I wrote a blog post a few days ago: business logic architecture model (transaction script, table module, activity record, and domain model). This article only gives a rough description of common design methods, I feel like I'm not doing anything. After several days of research and verification, there are some new understandings.

Although these are four independent architecture models, they are not unrelated. Except for the table modules rarely used in large software, transaction scripts and activity records are often used in combination, and activity records and domain models are also available. First, let's talk about the former.

Activity records have many advantages and obvious disadvantages. The biggest drawback is that a table corresponds to a model, and business operations are basically based on a single table. When a cross-Table logic occurs, the transaction script cannot be handled. In this case, you have to turn to the transaction script and sometimes write the transaction script directly in the model, sometimes a xxxhandler or xxxmanage is created above the model to implement the transaction script. If there are more and more associations between objects, your transaction scripts will become larger and larger, and there will be more and more duplicate code, and the project will be uncontrollable.

For the domain model, its construction model is not static, and many of its variants are similar to activity records. The conventional approach is to map the domain model directly to the database, with no other layers in the middle. However, there is also a variant that adds the entity layer between the database and the domain model. Each entity corresponds to a table, and the domain model is built on the entity in the way of inheritance or re-writing. The object only has data. Its crud is completed by the upper layer or other objects, or the object can implement its own crud. The domain model completes the business logic by operating the crud of each object. Isn't the later architecture like the architecture of activity record + domain model?

Next we will continue to look at the domain model. For example:

 

Throughout the software architecture, Bo (Business Object) uses Dao (Data Access Object) to operate Po (Persistent Object) to implement business logic. For VO (page display object), Po is displayed directly in a single table. In multiple tables, multiple Po objects are merged into a DTO (data transmission object) then, it is displayed. If an object has only data and its crud is completed by the upper layer or other objects, the Bo contains the DaO object. For crud implemented by the entity itself, both Bo and Po objects contain Dao objects.

From the technical perspective, activerecord can effectively implement the activity record mode. nhib.pdf supports both activity record and domain model, mysoft in the garden is also a distinctive framework integrating activity records and transaction scripts, Microsoft's Enterprise Library and yueue in the garden. adokeycap is a good transaction script framework.

In fact, I still have a lot of questions about these architectures. After reading these questions, if you find that I have made a mistake, you can make a brick to correct it and let me grow up in the spark of a collision of ideas.

 

References:

Object-oriented hql

 

Concept and function of Po Bo vo dto pojo Dao (with Conversion Diagram)

 

Java terminology (PO/pojo/Vo/bo/Dao/DTO)

Activerecord Model