System design is actually interesting-from the perspective of business logic

Everyone has their own opinions on what business logic is. I will talk about my own ideas and welcome to discuss them.

I want to determine whether a part is business logic. One of the simplest methods is to compare it with another system. If the problem does not exist in another system, it is the business logic of the system, otherwise it is not.

Business Logic is the essence of a system that distinguishes it from another system.

For example, for the approval process of a cash reimbursement form, the approval permissions of different personnel for different amounts are clearly in the scope of business logic, because leave approval procedures do not have this problem.

An application form must indicate the agent and agent, which is the business logic of the leave review procedure.

The business logic also includes:

Leave form must indicate the person on leave, time of leave, reason, and leave.

The application form has four statuses: draft, under review, approved, and rejected

Annual leave within one year, seven days in five years, ten days in ten years

Sick leave cannot exceed 30 days a year.

Only the draft form can be deleted.

Leave is approved by the General Manager for more than 20 days.

Only the Personnel Supervisor can view the leave information of all departments.

The department supervisor can only view the data of the Department

Any system user can only view his/her application form.

After the application form is approved, the data will be transferred to the company's attendance system

...

The descriptions, rules, permissions, and processes of these business objects should all belong to the scope of business logic.

In contrast, it is a non-business logic part and should be considered in all system designs:

1. How to implement data access (and transaction processing)

2. Exception Handling

3. How to Implement logging and tracing

4. cache policy design

5. dynamically assemble and update and replace objects

6. UI Representation

7. How to connect the UI and system services

8. How the system is layered and how the layers are connected

...

I think the above is the basic framework of a system and the underlying architecture of the system.

 

Therefore, the entire system is divided into two problem domains.

1. business logic: it has nothing to do with how the system is implemented, such as C #, Java, B/S, WinForm, Oracle, or SQL Server.

2. underlying architecture: it has nothing to do with the business logic and is mostly related to the software implementation method.

 

Most of the time, users are concerned about business logic. Of course, they may require Oracle and web implementation. If so, the design of the underlying architecture depends on a specific platform.

 

In many cases, the UI also has business logic.

For example, for different categories, the ticket is displayed in different colors, which is also part of the business logic.

If (approved)

Color = "green"

Else if (rejected)

Color = "red"

Else if (under review)

Color = "blue"

Else

Color = "black"

 

This is because the UI program needs to be modified when another State (such as return) is changed.

(PS: the business logic mentioned here corresponds to the basic architecture. It is different from the extensions of the UI, business logic, and data access layers of other friends in the garden)

 

Identify the business logic and how to implement the business logic during design.

The most traditional method is structural Analysis and design, namely SA (Structure Analysis) and SD

Of course, there are also popular object-oriented analysis and design, namely OOA and OOD.

In fact, either way, the implementation of business logic is basically divided into a static representation, and dynamic behavior.

Such as leave application

The entity (or object) of the application form is to be created. During the establishment process, the business rules of the application form may be programmed. For example, you must enter the leave start and end dates.

In principle, this application form will always exist in this system (of course, without deletion). Then, as long as you see such an object or a piece of data, you can use this object to know the meaning of a certain application form (or object. That is, the static representation of the business logic.

This corresponds to dynamic behaviors. Such logic can be implicitly implemented through system operations (often interactions between people and systems), such

The system rejects a visitor's view request for a ticket without permission.

The system sent an application form that took more than 20 days to the general manager for review.

The system grants the General Manager the permission to review the special application form after logon.

 

For the implementation of these logics, the system generally does not leave traces, but it does do this part.

Whether it is to distinguish the underlying architecture or to identify a variety of business logic, a final goal is to reuse.

Only reuse makes our work meaningful.

 

Extract the permission requirements from the business logic and provide a reusable permission solution.

Extract the process from the business logic to provide a general workflow solution.

Extract data verification from the business logic and provide a general verification solution.

Extract the requirements of business logic for multiple languages and provide a universal multilingual solution.

Extract the same or similar requirements of the business logic for the UI to provide a general UI solution.

And so on...

 

From the underlying architecture to general business logic solutions, the more these jobs are done, the less specific system development will be done. How can we balance them, this is a manifestation of the capabilities of system architects.