Transaction script and Domain Modeling

Currently, two common methods of project architecture are transaction scripts and Domain Modeling.

 

Transaction scripts have no architecture. They only use the natural architecture provided by the existing mature technology platform, or such as. NET and J2EE, to provide the transaction scripts and their implementation environments.

The transaction script directly develops SQL and GUI, and directly operates the database through SQL In the GUI or public class.

Domain Modeling improves the design of the domain layer, limits the persistent storage layer to some data that must be stored, and supports GUI replacement and expansion. Domain Modeling or the product of OO. From this perspective, transaction scripts are more inclined to process-oriented development based on the OO technical architecture. Domain Modeling makes better use of OO ideas.

Although transaction scripts are suspected of being process-oriented, they are indispensable in some scenarios. For example, they have high requirements on the Performance of database operations, or if the data required by the customer is close to the database or the data is large, it is necessary to narrow the distance between the GUI and the database in the architecture design. The SQL statement is naturally close to the database, especially in some report statistics requirements.

Therefore, SQL Server puts forward the OLAP/reporting service technology, which is to explore the modeling space at the database level, so that the database layer, especially OLAP, can do more, to make up for the inefficiency of the domain logic layer.

At present, the OLAP/data warehouse technology is developing rapidly, which is mainly based on the weakness of Domain Modeling in the big data hour statistics.

 

Another mode is called the "Table module", which should be a strong naming method for database tables, such as using oledb and a strong dataset to perform crud processing on database tables. This approach is rarely used except in some special scenarios.

 

If OODB is released, the transaction script will no longer be used, but the table module will appear in a new situation and may replace the current transaction script, in some small applications, there is a "flash of life ".

After the emergence of OODB, it is equivalent to implementing the ORM on the DB layer. Of course, it also increases the cache and improves the access efficiency. At the same time, Domain Modeling is based on relational databases. At the same time, Domain Modeling will include OODB Design.

Currently, the development is based on relational databases. Therefore, after Domain Modeling, you need to write persistent objects to the database. You Need To Use ORM between Domain Models and relational databases. In one of my frameworks, I also added the convertor layer to process the conversion between Domain Models and relational models/persistent class objects. It is really quite troublesome. At present, the persistence class design of ORM is restricted, and it is difficult to fully integrate into Domain Modeling.