Shulou(Shulou.com)06/03 Report--

This article mainly introduces "what are the reasons why the application architecture needs classified thinking". In the daily operation, I believe that many people have doubts about the reasons why the application architecture needs classified thinking. The editor consulted all kinds of materials and sorted out the simple and useful operation methods. I hope it will be helpful for you to answer the doubts about why the application architecture needs classified thinking. Next, please follow the editor to study!

The importance of classification

The so-called classification is to classify a given thing according to a certain standard. We humans are born with an instinct for classification, for example, when we look at the picture below.

No matter who sees the above six black dots at first glance, he will think that there are two groups of ink dots, three in each group. The main reason for this impression is that the human brain automatically organizes everything it discovers into some kind of continuous organization. Basically, the brain will think that there is some connection between everything that happens at the same time, and will organize these things according to some logical pattern.

The reason why our brains have this instinct is that there is a limited number of ideas or concepts that people can understand at a time. As George Miller pointed out in his paper "the wonderful number 7". The short-term memory of the human brain cannot hold more than seven memory items at a time. Therefore, when the amount of information is too large, only classification and grouping can help us to understand and deal with the problem.

In fact, since ancient times and the present, human beings have been doing classification / classification. As early as the Spring and Autumn period, the concept of "birds of a feather flock together" was put forward in the Policy of the warring States.

In the Internet industry, we will classify customers and then operate tiered for different customers.

What we usually call analysis and synthesis is actually the ability to classify. Analysis is to find differences in a class, synthesis is to find connections and commonalities in different things, and this commonality is equivalent to the dimension of classification.

The ability of classified thinking directly embodies the ability to see through the nature of things.

Classified thinking in Application Architecture

Concept definition

Before we discuss architecture, let's clarify the concepts of Module, Component, and Package.

Because there has always been a lot of ambiguity in these concepts. This can be seen through dozens of questions on Stack Overflow asking about these conceptual differences, as well as a variety of answers.

In a Stack Overflow post [1], we see the following answer:

The terms are similar. I generally think of a "module" as being larger than a "component". A component is a single part, usually relatively small in scope, possibly general-purpose.

However, another Stack Overflow post [2] has a different answer:

There is n o criteria to measure which one is greater than the other. One component can contain list of modules, and one module also can contain many co mponents.

In the book implementing Domain-driven Design, the author describes it as follows:

If you are using Java or C#, you are already familiar with Modules, though you know them by another name. Java calls them packages. C# calls them namespaces.

However, in AngularJS's design document [3], it defines Module and Component as follows:

The module can be considered as a collection of components, Each component can use other components. One of many modules combines up to make an Application.

By comparison, combined with my own understanding, I more agree with the definition in AngularJS, that is, Module is a larger concept than Component. For example, in Maven, Module is the first level that makes up Application, while the granularity of Component is generally smaller than that of Module, and multiple Component form a Module.

Therefore, before going any further, I would like to define these concepts as follows:

Application (Application): application system, consisting of multiple Module, represented by a box.

Module (Module): a Module is made up of a set of Component, represented by a cube.

Component (Component): represents an object that can provide some function independently, represented by the component diagram of UML.

Package: Package is relatively tricky, which is an organizational form, and granularity is not one dimensional, that is, a Component can contain multiple Package, and a Package can also contain multiple Component.

Based on the above definition, their Notation looks like this:

Elements of the application architecture

There are many definitions of architecture, and my favorite and most concise definition is:

That is, architecture is a kind of structure, which is composed of objects (Components) + relationships between objects + guidelines.

The same is true of application architecture, from a large level, enterprise applications can not escape the three-tier structure shown in the following figure, namely front-end, back-end and database.

For back-end development, the application layer is our main battlefield, but also the most complex part of the whole system (of course, the front end is not simple), where all the business logic converges. So, for the application layer, we need to split it further, not just write the business logic here.

Further layering of the application layer forms the four-tier structure advocated by COLA, which corresponds to four Module in Maven and four Jar after compilation and packaging. A typical application has the following Module structure:

Cloudstore-adapter cloudstore-app cloudstore-domain cloudstore-infrastructure cloudstore-client start

When the business becomes complex, this hierarchical structure is naturally better than no layering at all. This is also the problem that COLA has been trying to solve-- controlling complexity.

Everything from COLA 1. 0 to COLA 3. 0. I have come to understand that as an application architecture, the core of COLA is not to provide functions, but to provide Archetype.

At 1. 0, COLA provides Interceptor capabilities, Event Bus capabilities, and extension point capabilities. One is that I think people "need" these, and the other is that the framework of NB should be comprehensive, and few advanced features are embarrassed to open source. It turns out that I made a habitual mistake-overdesign. Interceptor can be completely replaced by AOP, and internal events and extension points are rarely used. So in COLA 3. 0, these "chicken ribs" were decisively removed and only extended functions were retained.

Returning to the nature of architecture, the core of COLA should be to define the structure and specification of the application, that is, the application architecture base model (Archetype). Instead of obsessing about the icing on the cake.

Upgrade to COLA 3.1

In fact, COLA 3.0 is almost done with this kind of comeback work. In this upgrade, in addition to further removing the functions of Event Bus, the most important thing is to re-standardize the subcontracting strategy and expand the responsibilities of the original control layer (Controller).

Subcontracting strategy adjustment

Layering is a horizontal segmentation in the functional dimension, that is, each layer has its own responsibilities.

Adapter layer: routing user request + adaptation response.

App layer: receive requests and do business processing together with domain layer.

Domain layer: domain model + domain capability.

Infrastructure layer: technical details (DB,Search,RPC..) + anticorrosion (Anti-corruption).

There is no problem with hierarchical processing, but this functional division will cause a problem, that is, the cohesion of the domain dimension will be affected. There is no problem when an application is responsible for only one area. However, when an application contains multiple business areas, the disadvantage of this lack of cohesion is more obvious.

A better subcontracting strategy is by domain rather than by function. Because the domain is more cohesive, the function serves the domain and should belong to the domain.

However, unfortunately, in the COLA application architecture, we need to integrate the division of horizontal functional dimensions and vertical domain dimensions, both of which are very good, and we want both. What shall I do? We can adopt the method of combining physical partition with logical partition.

Horizontally, we use Module to do hierarchical division, which belongs to physical division. Vertically, logical partition is carried out through Package. Finally, a structure is formed as follows:

According to this idea, in a project, the top-level package under Module is no longer a function, but a domain:

The subcontracting strategy according to the domain brings at least two benefits:

The system is more understandable and maintainable. In vernacular terms, it is easier to find something.

To facilitate the future split, for example, the order domain (Order) becomes more and more complex and needs to be removed, we just need to migrate the things under the Order to a new application.

Replace Controller with Adatper

The name Controller mainly comes from MVC, because it is MVC, so it has its own brand of Web application. However, with the rise of mobile, there are very few applications that only support the Web side, and it is usually standard to support all three ends of Web,Mobile,WAP.

In this context, the narrow control layer can no longer meet the demand, because in this layer, we not only have to do route forwarding, but also do multi-terminal adaptation, similar to the role of Driving Adapter in hexagonal architecture. In view of this, we use the adaptation layer (Adapter) to replace Controller, on the one hand, to echo the hexagonal architecture; on the other hand, we do need to do multi-terminal adaptation.

Based on this change, I refactored COLA Archetype to highlight Adapter as a level. In fact, Infrastructure is also an adapter, adapting (or decoupling) to technology implementations. For example, I need data to help construct Domain Entity, but I don't care whether the data comes from DB, RPC, or Search, or I can switch freely in these technology implementations without affecting the stability of my Domain and App layers.

The modified COLA will be adjusted in terms of architecture style, modules, components and subcontracting strategy. For specific changes, please refer to the following two diagrams.

COLA architecture diagram:

COLA3.1

COLA component diagram:

For more information about COLA 3.1.0, please visit:

Https://github.com/alibaba/COLA .

Classified thinking in organizational structure

The application of such an important thinking ability is certainly not limited to the scope of architectural design. As we have said at the beginning, classification is our human instinct and an important means of analyzing and synthesizing problems.

Production relations determine productivity, a good organizational structure will help business development, on the contrary, it will drag the business back. Therefore, the CEO of large companies spends a lot of time on organizational design every year, which is why, in large factories, we see a lot of organizational adjustments every year.

See an article "what is Apple's organizational structure" [4], which introduces that Apple's success has something to do with its excellent organizational structure. As shown in the following figure, traditional enterprises prefer business-oriented organizations, while high-tech enterprises tend to functional organizations.

Do you feel that Apple's organizational structure is the same as our COLA thinking:), physically, by function; logically, by business and product.

Apple's organizational design is because it is a technology-and innovation-driven company, the cost of collaboration is not the biggest problem, lack of expertise (technology is not good), lack of innovation is a matter of life and death. So he would rather sacrifice collaborative efficiency than ensure professionalism, that is to say, the camera only does the camera, the iOS only does the iOS, and the technical leader reports directly to the CEO, which can determine the development direction of the product. Because they are more professional in this field.

Steve Jobs had the view a long time ago that Apple managers should be experts in their management field. In an interview in 1984, he said:

We went through that stage at Apple, and we went out and thought, Oh, we're going to be a big company, and let's hire professional managers. We went out and hired a group of professional managers. It doesn't work at all. They know how to manage, but they know nothing professionally. If you are a great person, why do you want to work for someone you can't learn anything about? Do you know what's interesting? Do you know who is the best manager? They are great individual contributors. They never want to be a manager, but decide that they must be, because no one else can do a good job.

To tell you the truth, after reading this article, I am very impressed. On the one hand, I admire Jobs' insight, and on the other hand, I feel sorry for our industry. Business technology is also technology, but there is no decent environment and soil for the cultivation and development of technology.

Today, how much of the business technology Leader is focused on technology, as if it has become a business Leader. If the technical Leader becomes a pure manager, then who cares about the technology, who cares about the code, and who cares about the growth of engineers?

Taxonomy is both a science and an art

Finally, I still want to be moderate, classification is very important, but also very difficult, with a certain degree of subjectivity. Just like Bill. What Bryson said in A brief History of all things:

Taxonomy is sometimes described as a science, sometimes as an art, but it is actually a battlefield. Even today, the system is even more chaotic than many people think. Take the division of doors that describe the basic structure of biology as an example. Many biologists insist on a total of 30 gates, but some think it is about 20, while Edward's number in the Diversity of Life is as high as an astonishing 89.

If we look at things from different perspectives and have different degrees of understanding of the problems, we will get different classifications. Take COLA, for example. Until the current version 3. 1, I personally think that its layering and subcontracting are relatively reasonable. However, it is likely that the classification will change in later iterations.

The organizational structure is classified in the same way, according to business and functions. The key depends on whether the classification matches the characteristics of your organization. There is no best classification, only the most appropriate.

At this point, the study of "what are the reasons why the application architecture needs classified thinking" is over. I hope to be able to solve your doubts. The collocation of theory and practice can better help you learn, go and try it! If you want to continue to learn more related knowledge, please continue to follow the website, the editor will continue to work hard to bring you more practical articles!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.