Brief Discussion on software design driven by business model

 

During my years of work, most of the projects I have done in the past few years are database-driven. I think many of them are similar. For database-driven projects, our core is to develop around the database, and we are usually writing crudCodeLater, with the code generator and Orm, our work became fewer. However, do you think that although you have been using object-oriented languages for development, we usually do not have much improvement in the ability to use object-oriented design. In the past few years, I have moved away from a database-driven project and entered a strange field. At the beginning, it is very difficult because you need to abstract the business model of the system from your needs, the right or wrong design of the business model will directly affect the stability and scalability of the system. This is what I think is the work of software designers.

Later I met a project, and I realized that I would use business objects for modeling. The data used for calculation of business objects is obtained or saved according to the characteristics of business objects. This makes me suddenly enlightened. In these design processes, I began to understand the benefits of the design model and started to look at the system from a holistic perspective. Your perspective has been improved, so what kind of database, message queue, and cache are used for the system, you will think that these problems only aim to make full use of the capabilities of the business objects. The core of these problems lies in the Business Objects. For business objects with high computing strength, you can design multi-threaded, multi-process, or distributed objects for them. Everything is centered on the business, and the business object is the first citizen in the system. I think this is the design and implementation based on object-oriented.

Looking back, we can use a business model-driven design to restructure a database-driven project. Generally, we create DB-based projects first, and then generate code using the code generation tool. For ORM (Object relationship ing), it only solves the problem of constructing an SQL statement from the perspective of structured query, and then converting the returned structured data into an object. This has a big problem: the design of dB and the Business Objects of real systems are often difficult to integrate. In this case, our business objects have to take care of the DB Design During design. Otherwise, the data storage of business objects will be a big problem (at least not so good ). In fact, I think the correct method should be: First, analyze the core business model of the system. When the business model is determined, determine the Business Object Data to be persistent. On this basis, we re-design how to save data for the data persistence of business objects. Of course, the database also has the advantages of the database, for the query of a large amount of data and the storage of historical data using DB is still the best choice.

In the most recent project, the project owner had little knowledge about the software because of hardware. When the requirement document has not yet taken shape, let me first design the database structure of the system, which makes me very worried. I finished my work as a last resort. With the establishment of the business model, I found some database objects that I could not use. I had to create a data object class for the domain model again, use the new data object class to call the data object class generated based on the database through some contract methods to complete reading and saving. Of course, you will ask me why the database structure is not restructured. The problem is that the habits of the engineers responsible for the UI in the project are more inclined to be DB-driven, so ....... I guess there will be a lot of questions like this. Many people are still accustomed to using database-driven methods to complete their work.

Design Procedure

1. Confirm the domain model in the system with engineers familiar with the current field after receiving the requirement;

2. The domain model should be modeled and confirmed multiple times with the domain engineers to obtain a domain model recognized by both parties;

3. Design the business model (class) of the system based on the domain model );

4. Implement business models and tests;

For data storage issues of business models, different persistence storage can be performed based on the nature of business models and system requirements;

Generally, the storage includes:

A memory

B files (flat files, structured files, relational databases, non-relational databases, queues, etc)

Generally, the business model is the core of the entire system. Generally, customers' requirements will change. Therefore, when using the business model, our UI needs to be programmed based on the business model interface. Generally, I use a simple factory or IOC container to process object creation and dependency between objects. For other aspects of the system, such as logs and permissions, I will inject the business model through AOP, so that our engineers can focus on the implementation of the business model.

With the design philosophy that the business model is the first citizen, all other operations should be centered around the business model. For example, for data storage of the business model, we have a lot of options for persistence, you can select different data storage methods based on the data characteristics of the business model. For a simple non-system-driven business object, its data can be saved as a flat file or structured file. For system-driven business objects, the data can be stored in the database.