Backend Design Summary
The back-end system is mainly divided into several types: managing people, managing affairs, and managing things.
There are two types of systems managing people, internal and external. External systems include CRM (customer service management system) and internal attendance systems;
Managing affairs, in short, is what people can do and how they can do things. The most classic ones are the data statistics backend and the business flow management backend; Manage things mainly refers to the E-commerce management backend, which is used to manage commodity transactions.
However, in essence, the backend mainly includes three aspects: authority management, workflow, and record flow. It can be boiled down to one sentence, who can do what and what records need to be generated: who-where-how-what for short
Permission management (who-where)
Permission management, at present, mainly allocates authority through three aspects: user, role, and resource. Specifically, it is to give users a role, and the role can access and operate resources of different scopes. By establishing a role system, users and resources are separated to ensure the implementation of permission allocation.
So, how can permissions be designed?
If it is a business flow background, when designing permissions, roles can be designed according to business types, such as customer service, operations, and rechargers; if it is a data statistics backend, roles can be designed according to user types, such as external users and internal personnel; if If it is a CRM, it can be divided according to the user's position level. After the first-level division, it is often necessary to subdivide roles. For example, customer service can be subdivided into ordinary customer service, customer service team leader, and customer service director. The data that can be accessed and manipulated can be controlled through the division of levels.
In addition, when refining the role, there are two points to pay attention to:
- For roles of the same type, what is the relationship between the permissions of the subordinate and subordinate roles? Can the upper-level role operate the business of the lower-level role? Does the Add product operation need to be reviewed by a superior?
- For external users, should the permission be separated, or should it be handled in two different backend? The former is more convenient to implement, depending on the system's consideration of security; the latter is more secure and more convenient in data processing.
Although we put permission management in the first place, in the actual development process, the allocation of permissions is often implemented after the entire backend development is completed (mainly to avoid the impact of permission settings on development).
Workflow (how)
Workflow refers to "the automation of part or the whole of a business process in a computer application environment". It is an abstract and general description of the business rules of the workflow and its operation steps.
The main problem solved by workflow is: in order to achieve a certain business goal, use a computer to automatically transfer documents, information or tasks among multiple participants according to certain predetermined rules.
When designing workflow, in addition to the most basic single backend workflow design, there is also the design of workflow between multiple backend. OK, let’s start with the most basic single backend. The workflow design is actually very similar to the demand design of consumer products:
1. After understanding the business requirements, produce suitable business flow charts (the business flow charts are not expanded here, and will be written in a separate chapter later), state diagrams (some simple workflows do not need this), and through business Flowchart to better communicate business requirements to development
2. Build the product architecture diagram of the workflow, which mainly lists the feature modules involved in the workflow (broad thinking). At this time, the product architecture diagram can be collided with others; why not use the product prototype diagram? The following reasons:
(1) The production cycle of product prototypes is long, which is not suitable for early thinking collisions.
(2) Product architecture diagrams are easier to rework than product prototypes and can be iterated faster
(3) It can be discussed at low cost for the needs of later addition, so that when developing and designing the library and table, it is better to consider the scalability
3. Through the first two steps, the workflow can basically be better passed to the R&D side; then, the product architecture diagram can be refined, and to what extent? It is best to refine the points involved in the workflow, so that when producing product prototypes, you can think more comprehensively about the interaction between a single module and the entire back-end system
4. In the third point, the refinement of the product architecture diagram was mentioned, and then, it was time to the boss—the product prototype diagram
5. Repeat the above points 3 and 4 appropriately, so that a more complete workflow is designed
After the prototype of the product is released, it is about to start a more ferocious physical collision with R&D. The details of the physical collision will not be expanded here, but it can be added: Make a product with patience!
What is described above is the workflow design in a single system, so what is the difference between the workflows processed by multiple systems?
First of all, in terms of design, the basic process will not be differentiated. The main thing is to communicate more with the system architect, so that the workflow of a whole system can better meet the business needs. When communicating, it is best to first draw up an imaginary architecture diagram by yourself. This output focuses more on the data interaction between different systems, indicating the output and input between systems. In this way, the workflow can be better designed on the basis of setting the architecture that meets the needs.
Secondly, there is another detail that needs to be paid attention to, that is, in the prototype diagrams of different backgrounds, it is necessary to clearly describe whether the workflow interacts with other modules, which is convenient for yourself and others.
Record Flow (what)
When the backend system is designed, there is often a special operation log to record the operation track of the backend user, mainly because the backend data is more valuable to the enterprise, so it needs to be protected.
In general, the record flow is mainly divided into two types: operation track and data query.
The operation track is easy to understand. It is the record generated by the user's operation of the data in the backend, which needs to be recorded one step at a time. In this way, when designing, it is OK to clearly list the initial state, change state, operation content, operator, and operation time. There is little difference between different businesses, and it is regarded as a standard module in the backend.
Data query, in this case, is more of a feature module that organizes the data generated in the workflow and then forms it. In this case, every step will not be recorded like the operation track. Instead, it will be designed according to specific business needs, so that users can query, understand, and analyze data at different latitudes in the backend to obtain value.
In addition to the above three basic modules, there is another point to pay attention to when designing the backend. Try to use the default control for design, and use a more unified interaction mode between different modules, so that development is more efficient.
If you like the article, please share it with others with page link, thanks for your supporting! ❤
Leave a comment