** Introduction: ** How to define architecture? What are the elements of an application architecture? What is categorical thinking in application architecture? Zhang Jianfei, author of open source application architecture COLA, introduces his thoughts and experience in the architecture design of COLA and shares his approach to application architecture.

Module, Component, Package, these concepts are not unfamiliar to us technical students, but not all of us can understand their essence.

After in-depth understanding, I found that the deep meaning behind it is classified thinking. This classification is also the core of the application architecture, through different granularity, different levels of classification, the implementation of complex software system control to be understood, can be maintained. Otherwise, there is no way for human beings to understand and maintain software with a million lines of code on it.

Imagine, to an extreme, if we could write all our business logic in a single class without these concepts to help us categorize. Many of our “non-human” systems are the result of a failure to properly classify them.

Early on, one of the main reasons I didn’t like JavaScript was because it lacked concepts like Package and JAR in Java, leading to a loose, arbitrary organization of code. This problem was not solved well until ES6 and React. Before this, front-end engineers had to rely on seaJS and requireJS frameworks to do modular and component-based things.

At this point, you might be wondering, what’s the magic of categorization? How is this the core of an application architecture? Don’t worry, Sir. I’ll explain it in detail.

The importance of classification

The so-called classification is the division of groups of given things according to certain standards. We humans are hard-wired to categorize, for example, when we look at the graph below.

​

Anyone looking at the six spots would think there were two groups of three. The main reason for this impression is that the human brain automatically organizes everything it finds into some sort of continuous organization. Basically, the brain thinks that everything that happens at the same time is somehow related to each other and organizes them in a logical pattern.

The reason our brains do this is because there is a limit to how many ideas or concepts a person can comprehend at one time. As George Miller put it in his paper “The Wonderful Number Seven”. The human brain’s short-term memory can’t hold more than seven items at a time. Therefore, when there is too much information, only categorization and grouping can help us understand and deal with the problem.

As a matter of fact, human beings have been classifying since ancient times. As early as the Spring and Autumn Period, the concept of “birds of a feather flock together and people flock together” was put forward in “Strategies of the Warring States”.

In the Internet industry, we categorize customers and then operate in layers for different customers, which is the same reason.

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

The ability of categorical thinking directly reflects the ability to see through the essence of things.

Categorical thinking in application architecture

Concept definition

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

Because these concepts have always been quite ambiguous. You can see this in the dozens of questions and responses on Stack Overflow asking about these conceptual differences.

In a Stack Overflow post [1], we see this response:

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.

Another Stack Overflow post [2], however, has a different answer:

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

In the book Implementing Domain-Driven Design, the authors have this description:

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 the AngularJS design document [3], it defines modules and Components like this:

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.

​

Based on the comparison and my own knowledge, I agree with the AngularJS definition that Module is a larger concept than Component. For example, in Maven, Modules are the first level of Application, and Components are usually smaller in granularity than modules. Multiple Components make up a Module.

Therefore, before going any further, I deliberately define these concepts as follows:

• Application: An Application system consisting of multiple modules, represented by boxes.
• Module: A Module is composed of a group of components, represented by a cube.
• Component: Represents an object that provides an aspect of functionality independently, represented by a UML Component diagram.
• Packages: Packages are tricky. They are a kind of organisation and their granularity is not one dimensional. That is, a Component can contain multiple packages, and a Package can also contain multiple components.

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

​

Application architecture elements

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

​

That is, architecture is a structure composed of Components + relationships between objects + guidelines.

The same is true of application architecture. On a large scale, enterprise applications cannot escape the three-tier structure shown in the figure below: front end, back end, and database.

​

For back-end development, the application layer is our main battleground and the most complex part of the whole system (of course, the front-end is not simple), where all the business logic is gathered. So, for the application layer, we need to break it down further, not just write the business logic here.

Further layering of the application layer creates the four-tier structure advocated by COLA, which in Maven corresponds to four modules, compiled and packaged with four Jars. A typical application would have modules that look like this:

<modules> <module>cloudstore-adapter</module> <! Adapter layer --> <module> Cloudstore-app </module> <! <module> Cloudstore-domain </module> <! <module> Cloudstore-infrastructure </module> <! <module> Cloudstore-client </module> <! --RPC SDK--> <module>start</module> <! --SpringBoot --> </modules>Copy the code

When the business becomes complex, this hierarchy is naturally better than no hierarchy at all. That’s what COLA has been trying to do — control complexity.

From the details of COLA 1.0 to the simplicity of COLA 3.0. I have come to understand that the core of COLA as an application architecture is not to provide functionality, but to provide Archetype.

In 1.0, COLA provided Interceptor capabilities, Event Bus capabilities, and extension point capabilities. One is that I think people “need” these, the other is that I feel NB framework should cover everything, there are few advanced features are embarrassed open source. As it turns out, I made a mistake of inertia — overdesigning. Interceptor can be completely replaced with AOP, and internal events and extension points are rarely used. In COLA 3.0, these “chicken ribs” were removed and only extension points were retained.

Getting back to the essence of architecture, the core of COLA should be defining the structure and specifications of the application, the Application Architecture Archetype. Instead of obsessing over the icing on the cake features.

Upgrade to COLA 3.1

In fact, COLA 3.0 does more than enough of that. In this 3.1 upgrade, in addition to further removing the function of Event Bus, the most important thing is to re-standardize the subcontracting strategy and expand the responsibilities of the original Controller.

Subcontracting strategy adjustment

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

• Adapter layer: Routes user request + ADAPTS response.
• App layer: receives requests and performs business processing together with domain layer.
• Domain layer: Domain model + Domain capability.
• Infrastructure layer: Technical details (DB, Search, RPC..) + Anti-corruption.

There is no problem with hierarchical processing, except that the problem with functional partitioning is that the cohesion of domain dimensions suffers. There is no problem when an application is only responsible for one domain. However, the downside of this lack of cohesion becomes apparent when an application encompasses multiple business domains.

A better strategy is to subcontract by domain rather than by function. Because domains are more cohesive, functions serve domains and should belong to domains.

Unfortunately, in the COLA application architecture, we have to combine the horizontal functional dimension and the vertical domain dimension. Both are good and both want. How to do? We can combine physical partition with logical partition.

Horizontally, we use Module to make hierarchical division, which belongs to physical division. Vertically, logical partitioning is done through Package. Finally, the following structure is formed:

​

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

​

Subcontracting by domain brings at least two benefits:

• The system is better understood and maintainable, or in the vernacular, easier to find.
• For the convenience of later split, for example, the Order field becomes more and more complex and needs to be split out, we just need to migrate the things under the Order to a new application.

Use Adatper instead of Controller

The name Controller mainly comes from MVC, because it is MVC, so it carries the brand of Web application. However, with the rise of mobile, now few applications only support the Web side, usually the standard configuration is Web, mobile, WAP three to support.

In this context, the narrow sense of the control layer can no longer meet the requirements, because at this layer, not only routing and forwarding, but also multi-end adaptation, similar to the role of the Driving Adapter in the hexagonal architecture. In view of this, we replaced the Controller with Adapter, on the one hand, to echo the hexagonal architecture; On the other hand, it is also necessary to do multi-end adaptation.

Based on these changes, I reconfigured the COLA Archetype, highlighting the Adapter as a layer. In fact, Infrastructure is also an adapter, an adaptation (or decoupling) to a technical implementation. For example, I need data to help construct a Domain Entity, but I don’t care if the data comes from DB, RPC, or Search, or, I can switch freely between these technical implementations without affecting the stability of my Domain layer and App layer.

After the transformation, COLA will be adjusted in terms of architectural style, modules, components and subcontracting strategy. Please refer to the following two figures for specific changes.

COLA Architecture Diagram:

​

COLA3.1

COLA Component diagram:

​

Categorical thinking in organizational structure

Such important thinking skills must not be limited to the scope of architectural design. As mentioned in the beginning, classification is our human instinct and an important means of analyzing and synthesizing problems.

Relationships of production determine productivity, and good organizational structures help businesses grow, while vice versa. As a result, ceos of big companies spend a lot of time each year on organizational design, which is why, in big companies, we see a lot of organizational change every year.

I read an article titled “What is apple’s Organizational Structure?” [4], which introduced the relationship between Apple’s success and its excellent organizational structure. As shown in the figure below, traditional enterprises tend to be operational organizations, while high-tech enterprises tend to be functional organizations.

​

Do you feel that the organizational structure of apple is the same as that of COLA :), physically divided according to functions; Logically, divide by business and product.

An organization like Apple is designed because it is a technology – and innovation-driven company, where collaboration costs are not the biggest problem, but lack of expertise (technology is not) and lack of innovation is a matter of life and death. Therefore, he would rather sacrifice collaborative efficiency to ensure professionalism. That is to say, those who make cameras only do cameras, those who make iOS only do iOS, and the technical leader can directly report to the CEO and decide the development direction of the product. Because they are more specialized in this field.

Long ago, Steve Jobs had the idea that Apple’s managers should be experts in their fields. In a 1984 interview, he said:

We went through that phase at Apple where we went out and thought, oh, we’re going to be a big company, let’s hire professional managers. We went out and hired a bunch of professional managers. It didn’t work… They know how to manage, but they know nothing professionally. If you’re a great person, why would you want to work for someone you can’t learn anything from? You know what’s funny? Do you know who is the best manager? They are great individual contributors who never wanted to be a manager but decided they had to be because no one else could do a good job.

To be honest, after reading this article, I am deeply impressed. On the one hand, I admire Steve Jobs’ insight ability, and on the other hand, I also feel sorry for our industry. Business technology is also technology, but there is no decent environment and soil to cultivate and develop technology.

Nowadays, how many business technology leaders are still focused on technology? They have become business leaders. If technical leaders become pure managers, then who cares about technology, who cares about code, and who cares about the growth of engineers?

Taxonomy is both science and art

In the end, I’m going to strike a middle ground. Classification is very important, but it’s also very difficult and subjective. As Bill Bryson says in A Brief History of Everything:

Taxonomy is sometimes described as a science, sometimes as an art, but it’s really a battleground. Even today, that system is more chaotic than many people realize. Take the division of gates that describe the basic structure of living things. While many biologists insist on a total of 30 gates, while others suggest more than 20, Edward’s The Diversity of Life puts the figure as high as an astonishing 89.

We observe things from different perspectives, the cognitive degree of the problem is different, the classification will be different. Take COLA for example. Until now, in version 3.1, THE layering and subcontracting approach seemed relatively reasonable to me. However, it is quite possible that the classification will change in later iterations.

The same is true for organizational structure, which can be divided by business and function. The key is whether the categories match the characteristics of your organization, there is no best category, only the most appropriate.

In addition to the categorical thinking shared in this article, more thinking skills can be found in the author’s new book, The Road to Code Refinement: From Coder to Craftsman. This is a book written for professional programmers. It is divided into three sections: Craft, Thought, and Practice. It details programming techniques and methodology, abstraction, divide-and-conquer, common application architecture patterns, and COLA architecture design principles. Hope to help the majority of programmers to develop good programming habits and thinking.

Recommended reading

Why are Alibaba’s programmers growing so fast?

Top GitHub Offer comes to principle + framework, open sharing;

50W annual salary programmer need technology stack analysis

Three things to watch ❤️

If you find this article helpful, I’d like to invite you to do three small favors for me:

Like, forward, have your “like and comment”, is the motivation of my creation.

Follow the public account “Java Doudi” to share original knowledge from time to time.

Also look forward to the follow-up article ing🚀