Architecture Design-Brief description of business logic layer

The business logic layer is a layer dedicated to processing software business requirements. It is located on top of the database and under the service layer, and completes some columns of Domain Object CRUD, as a group of microservices provided to the service layer, the service layer is organized on the exposed to the performance layer, such as inventory check, usage validity check, and order creation.

The business logic layer includes the domain object model, domain entity, business rules, verification rules, and business processes. 1: The domain object model describes the system structure, including the object function description and the relationship between objects. The domain model is inherently complex: 2. The domain entity: The business layer is the processing of some operational business objects (BO. The business object contains data and behaviors, and is a complete business object. It is different from the data migration object dto mentioned in the simple understanding of the service layer in the previous architecture design. For dto, where data exists and there is no behavior, dto is a subset of boddd, also known as do, dto is a flat entity that is responsible for the specific interface requirements. dto is only a data carrier and must span application boundaries, while business objects do not have replication and migration, usually one or more data migration objects exist for a business object. 3: The biggest business logic is dealing with some real-world rules, which is also the most vulnerable part of the software, here we usually see a lot of if-else or switch-case. This is also because I personally think that our project should have the most relationship and separation needs. 4: verification rules: Business Rules are also used to verify the data of objects to a large extent, and verify the current data status of business objects. I think there should be a verification interface exposed to external objects for each business object. You can consider the Microsoft enterprise database's VAB declarative Authentication Based on Attribute or the smooth verification component in the previous section: fluentValidation validation component in FluentValidation is based on IOC decoupling.

Business layer mode: In Common Business Layer modes, the process mode and object-oriented mode are mainly divided. The process mode includes the transactional script and table mode, while the object-oriented mode is the activity record mode and the domain-driven mode. In theory, the transactional script mode is the simplest development mode, with initial investment, but with the increase in project cycle and complexity, and the domain model DDD) the early stage investment is large, however, theoretically, the project cycle and complexity increase linearly. Of course, these are theoretical values.

1: The transaction script mode is the simplest mode in the business logic layer and is process-oriented. This mode is used as a starting point to design business components, that is, operations that directly map business logic to the user interface. This usually starts from the logic of the presentation layer, the presentation layer what I need from the business layer to the data layer. For new features of other users, a new branch process from UI to relational database service is required. Its use and logic are not very complex or the application system development is not stable. It does not need to pay extra cost unrelated to the business, and can quickly develop applications with the help of modern VS and other ides. RAD ). This advantage is also the biggest disadvantage. The program is full of logic such as IF-else, switch-case, or a large number of static methods. Each function is a program branch, this Code cannot be reused. Coding is not easy to maintain and is not suitable for complex projects and changing requirements.

2: Table mode: defines a table module class for each database table, including all the behavior methods used to operate the data. As a container, data and behavior are organized together. The data granularity is for data tables rather than data rows. Therefore, data information must be transmitted in a set or table. The table mode is based on objects but fully database-driven development. It is not so suitable to meet requirements when the business model and database relationship model are significantly different. However, it is also a good option to automatically generate a large amount of code with the help of IDE provided in. net, such as strong-type DataSet, because some database operations tend to be automated. The table mode does not focus too much on the business, but on the database table structure. Business logic and domain problems are the core of software.

3: activity record mode: A pattern method that takes a Row in a database table as an object and contains behavior and data in the object. Its data objects are very close to the database table structure. In the activity record mode, an object usually contains business rules such as CRUD behavior and data verification of the operation object. The activity record mode can be used well if the business is not very complex and the object relationship and Relationship Model ing are not significantly different. The activity mode is relatively simple. With the help of many existing frameworks such as Linq to SQL and ActiveRecord, it will be very useful for projects that are not too complex in the problem field. However, the mode and the database table structure are mutually dependent. As a result, if you modify the database structure, You have to modify the object and related logic at the same time. If we cannot guarantee that the relational database model and object model are very similar, This is a dilemma.

4: domain model: In the previous models, projects started from the data-centric perspective, rather than the problematic business areas. Domain Models focus on the field of system issues. First, they are designed for domain objects. In terms of the activity record model, the domain model is completely on the side of the business concept model of the problematic domain. It is independent from the database and persistence, and it advocates persistence and transparency POCO ). It can make full use of object-oriented design and is not subject to any constraints of the persistence mechanism. In fact, it is completely business-driven. However, its biggest advantage is that the object model and the relational model have a natural impedance. Our domain entities need to map to the persistence mechanism sooner or later. Fortunately, there are currently supported ORM frameworks such as NHibearnate, EF, and Fluent NHibearnate. In DDD, the concept of UOW, warehousing, value type and aggregation root, domain events, and domain tracking will be described in detail later.

The model selection is determined by the architect, which is also a challenging responsibility of the architect. It is determined by the specific project requirements, teams, individuals, and other external factors. There is no omnipotent model, there is no perfect design.