I have taken over a new business system and I am so familiar with it.

story

Kitty continued to take responsibility, which was a huge blow to his heart. This was the first time in his career. If you are interested in the kitten's situation, you can learn about "idempotent events" and "cache breakdown events".

This day the team leader came to a conference room with Mao Mao.

So many accidents have occurred in such a short period of time. I understand that this is not easy for you. After all, you have just taken over this project. Maybe there are some problems with the project itself. Now the responsibility falls on you, I hope you won’t be discouraged...", the team leader continued.

The kitten looked at the chick and nodded, feeling relieved. I thought: "It seems that the team leader will not criticize my performance."

However, problems have arisen and there may be other problems with the system, including business, code, or design aspects. Please take the time to organize and prepare an analysis of your project documents. We look forward to having you share the current status of the system with you at our next monthly meeting.

Mao Mao nodded repeatedly, thinking in his mind, "This should be regarded as catching a model in disguise, that's all. But, how should I write such a document?"

At this time, the kitten began to feel uneasy again.

Let’s talk about getting familiar with new projects

When taking over a new system, how do you get familiar with it? In fact, Laomao asked everyone at the end of the last article "Cache Breakdown Incident". I wonder if you still have any impressions?

Now let’s talk about the process of Laomao becoming familiar with a new system. I hope these experiences are helpful to you, and you are welcome to share your own methods. The main steps are as follows:

Project familiarity

1. Try to draw a use case diagram

After receiving a new business system, we first need to at least know what the current system does, so sometimes we need to take time to find the relevant product manager to understand the business. At this time, the product manager may chat with you. Let’s talk about the current business status and background, but he may also directly throw you a V0-Vn version of the product requirements plan and tell you that he is not available. If it's the latter, remember to hold back and don't hit the product's face with the monitor, because your cooperation hasn't started yet... Just kidding, let's get down to business.

Let’s first understand what a use case diagram is.

Brief Analysis of Use Case Diagram

A use case is a functional unit in the system and can be described as an interaction between the executor and the subject. An actor is an idealized role of an external user, process, or other system that interacts with a system, subsystem, or class.

Purpose: Able to list use cases and executors in the system, and display which executor participates in the execution of which use case.

Let’s draw a use case diagram to illustrate the “order and payment business point” that Mao Mao encountered before. As shown below:

Example

The picture above is actually a simple use case diagram. What we need to figure out is the meaning of the various lines.

The
• a line represents the association, that is, the communication path between the executor and the use cases it participates in. Indicated by a solid line.
The
• b line represents inclusion, inserting additional behavior on the base use case, and explicitly describing the insertion.
The
• c line represents an extension, inserting additional behavior on the base use case, which the base use case does not know.
The
• d line represents use case generalization, the relationship between general use cases and special use cases, where special use cases inherit the characteristics of general use cases and add new features.

This way we can have a clear understanding of the current business status.

2. Back-end model combing

After sorting out the current system function points and business forms, we can step in and take a look at the existing system model, that is, the tables of the DB database. In this way, we can know how the currently designed system abstracts the business. Then when looking at the related tables, we can actually slowly draw the ER diagram.

What is an ER diagram

E-R diagram is the full name of Entity Relationship Diagram. It provides a method to represent entity types, attributes and relationships, and is used to describe the conceptual model of the real world.

Through its definition, we actually know that there are three important points in the ER diagram, namely entity classes, attributes, and connections. When we organize the DB table, it actually corresponds to our table, table fields, and the relationship between the corresponding tables and tables.

Look at an example. Let’s draw the underlying product logic of a general mall system.

ERExample

Explain the meaning of each picture:

• The box represents a model, which is a table. Of course, this is also an entity class in the ER diagram.
• The ellipse represents the attributes contained by the entity class.
• The diamond represents the action relationship between the two classes, such as the goods being put on the shelf in the picture above. In daily life, the teacher teaches students, so the diamond may be the class.
• The 1 and n on the line are clearer, which is a one-to-many, many-to-one, and one-to-one relationship.

In the picture above, we can actually see more clearly that there are three important entity concepts in the current system, namely commodities, commodity pools, and shelves. From the picture we can also roughly see the relationship between them.

After we sort out the ER diagram, it will probably be clear how the above-mentioned use case business diagram is abstracted in the existing system.

Having talked about this, let’s look at it from a God’s perspective. We have given the current system a skeleton, and then we have to make its heart beat, blood rush, and give the entire system a soul. Then, next, we will string the models together through the process.

3. Core process and state machine flow

Let’s take a look at the example directly. In fact, Laomao thinks that sorting out the flow chart may be relatively simple, but the difficulty is how to control the links in the entire process. If you think more carefully when drawing, you may record every step of the inventory. In this case, there will be less focus on business. If the drawing is thick, the corresponding relationship between the models may not be well controlled. Therefore, Laomao feels that this place is a test of the programmer's generalization ability and business understanding ability.

flow chart

In the above picture, Laomao simply drew a flow chart. Of course, there may be errors in the flow chart. Please don’t take it too seriously. This is just to illustrate such a thing. Let’s not talk about the accuracy of the business process inside. In the above process we see the following graphic content:

• The starting node is represented by a circle. Of course, you can choose the color you like. There are not many standards.
• When the process flows, we use related arrow lines to represent it, and when it comes to core business operations, it is represented by squares.
• When encountering a branch node, we use diamonds for routing.
• When encountering some asynchronous operations, Laomao likes to use dotted lines to represent them.

The representation of the above process is actually relatively simple, and we don’t need to care about the system boundaries. Just draw.

But our current development systems are often microservice-based, so at this time we may have to consider the interaction process between different systems. From this, we can introduce the concept of swimming lanes. See below.

Swim Lane Process

In the above figure, we can see the interaction between various system applications. Each swim lane represents one of the microservice systems. This is a picture that Laomao actually drew in his daily familiarity with the business. I would like to emphasize again that what you should look at are some ideas of the drawing, and don’t get too entangled in the business.

Let’s go into more details. For example, when discussing the flow of order status, in order to better control, we will use some status flow diagrams to sort it out.

Status flow

The above mainly explains the flow of the entire state in the process. Of course, many times when the state bits are relatively simple, we don’t need to draw them. Maybe we will consider drawing the state machine when the state is more complex and diverse.

The above is the detailed content of I have taken over a new business system and I am so familiar with it.. For more information, please follow other related articles on the PHP Chinese website!