[PaPaPa] system architecture construction analysis, papapa System Architecture

[PaPaPa] system architecture construction analysis, papapa System Architecture

Statement

[PaPaPa] This project is for the purpose of technology sharing and research. It is not a commercial project. Therefore, it provides more ideas. Do not use it directly in the project.

 

In the previous article, it was helpless to hide the address of an open-source project. In order to find a companion who had to do this together, I had to give a day's recommendation. I hope you can understand it here.

Starting from this article, we will completely disclose the project addresses and the details involved in all projects, including documents, discussion processes, design ideas, and implementation methods, and organize them into a series, this will be uncovered in subsequent articles.

 

This project and blog series will be written in the form of "giving a fisherman a fish, do your best to make a contribution to C # to give back to my happiness and improvement in my life.

At the same time, because this project does not involve distributed and big data content, this blog series will not have this content. Even if Redis is applied, it will only be used as a cache.

 

Finally, in the light of the idea that you don't want to miss others, you are welcome to make mistakes!

 

What is software architecture?

The software architecture is divided into logical architecture, physical architecture, and system architecture.

Generally, the System Architect will produce documents containing at least three parts, while some companies with detailed division of labor, the O & M Department (or other similar departments) will supplement or modify the server configuration and network section of the physical architecture.

It can be seen that a qualified System Architect has a terrible knowledge breadth.

Of course, this article is not a Wikipedia or Baidu encyclopedia.

 

How to generate system architecture

First of all, it is clear that it is omnipotent because it is a game of both considerations and trade-offs. No system architecture can be tapped into and said: I can apply it to any scenario.

The system architecture has a strong dependence on the business. The business is about the system architecture, and sometimes the system architecture may affect the proper adjustment of the business under special circumstances.

Since it comes to the business system architecture, it is obvious that there must be a business system architecture first.

 

Requirement document

The requirement document is the visualized output of the business. Under normal circumstances, this document is written by the product manager or demand specialist to describe the business contained in the software.

Next, we will simply take two brain maps that the 'tiger' casually draws when the PaPaPa project was created. The requirement documents are now available from v0.1-v0.4, the new version is being reviewed and is expected to be available next week.

The above two articles are just typical ones in the discussion. Of course, the formal requirement document will certainly not look like this.

 

System architecture construction process

 

Analysis of business modules

From the figure above, we can see that there are two major parts: Web and mobile,

As we were eager to drive out a prototype, we decided to move the mobile end to the back, so we only considered expansion without planning for the moment.

Although it has been extended, this must be taken into account when building the system architecture. Otherwise, subsequent modifications will cause you a headache.

 

Solution folder

The solution folder helps us classify class libraries.

Of course, naming varies according to everyone's preferences. Some projects may not have Test, and some may merge Business and Core.

However, our division is like this. The difference between the business and the core is that the core layer provides underlying data operations. Business to assemble these operations to meet business needs.

This part is in line with the above mentioned, and will be used as a mobile terminal in the future, while the mobile business is somewhat different from the Web end, regardless of the number of interfaces or interface content.

 

Class Library name

Take the business layer as an example. PaPaPa. Web. * is a group.

Where PaPaPa is the project name, and Web is the business module of which the Mobile end is named .*

 

How to differentiate the core layer, business layer, and infrastructure layer

There is nothing to say about other layers, so others are ignored. If you have any questions, you can raise them separately.

Let's take a brief look:

Core layer: it is surrounded by the business layer to provide underlying operation support for the business layer, such as DB and cache.

Business Layer: uses the functions provided by the core layer to encapsulate services of different modules.

Infrastructure layer: provides the most basic underlying support for all layers (excluding any business logic). The PaPaPa project is used as an example, including but not limited to: general cache operations (Cache monitoring) general class libraries, DB operations, general model-object ing, and cache operations. This layer should also have high portability. When creating a new project, this layer can be directly copied and used as an implicit standard.

 

When creating a new class library, placing it at the corresponding level based on the responsibilities of the current class library is an important identifier for the role of a class library in the system.

If you accidentally put a class library in the core layer into the business layer, There will be various redundant code, because different business modules are not allowed to reuse each other, unless you create another PaPaPa. basicBusiness. * similar to a module dedicated to basic business classification.

Of course, this is only from a reasonable point of view. If the designer cannot maintain the system architecture in the future, there will be a chaotic situation of cross-Invocation at all levels. At that time, project maintenance costs will be high!

 

Class Library responsibilities

Many of my peers think that the number of class libraries is too large, and few classes in some class libraries are puzzled.

In fact, the number of classes in the class library is not the key. The key is whether the responsibilities of the class library are clearly divided. Otherwise, each function will be placed in the same class library.

On the one hand, it will lead to a deep Folder level in the class library, and on the other hand, non-related services will be interrupted due to upgrades. The most important aspect is to increase the difficulty of system layering, because a library with a huge function is likely to span multiple layers.

 

The following are the responsibilities of each class library in the PaPaPa project. This is only one of the many classification methods.

As long as you classify the class libraries according to certain rules.

This allows developers to better understand the intention of the system builder.

 

Source code

This is just the beginning of this series. Later, we will add some important links and practical experience in writing this project.

Of course, it will include cache decisions that many people are concerned about, and how to add new underlying support without disrupting the intention of building the system.

To put it simply, cache decisions are divided into two parts: automatic decision making and manual decision-making. The bottom layer supports two levels, and why does some areas give up automatic decision-making due to flexibility problems.

Of course, this is a big name. It is actually a combination of common C # syntax.

 

Finally, Source Code address: http://git.oschina.net/doddgu/PaPaPa