Today, I will talk about hierarchical thinking and hierarchical model in architectural design and the logic of architectural composition based on hierarchical thinking.

Overview of architectural Thinking

For architectural thinking itself is still a collection of similar system thinking, structured thinking, programming thinking and many other thinking modes. Because the core role of architecture is to bridge the business real world with abstract IT implementations, at the heart of architectural thinking is an understanding of business-driven technologies that serve the ultimate business. To truly achieve the balance of business and technology, requirements and implementation, software and hardware, static and dynamic, cost and benefit through architectural design.

As mentioned in several previous articles, there are two priorities in architectural design, one is decomposition and the other is integration.

Decomposition is fundamental, and the point of architecture is to divide and conquer complex problems while maintaining high cohesion, loose coupling, and integration into an integrated whole. The core of decomposition is defining the problem, so the architecture still needs to understand the requirements first.

Integration is to complete decomposition of action, the final decomposition of the components or subsystems, through the appropriate interface design, finally can also be integrated as a complete whole, only to accelerate the development and reduce the problem complexity, if the content of the decomposed can’t together, then break down doesn’t make any sense.

Decomposition + integration can be understood as the core way of thinking and method of architecture.

After the decomposition is complete, a large system has been broken down into many smaller modules, or the implementation of a small module itself is divided into multiple step phases. Then scattered nodes must be aggregated and summarized upward to form a complete architecture.

And the key to the formation of this structure is to think in layers. Architecture layering is one of the most important aspects of architecture, through which we can better understand the overall business system or function implementation.

Cloud platform three-layer architecture: resource, platform, application

When planning the big architecture, we often refer to the standard three-tier architecture of cloud computing, namely IaaS layer, PaaS layer and SaaS layer. The IaaS layer focuses on IT infrastructure and virtualization; PaaS layer focuses on building platform layer service capability. For the SaaS layer, it’s application-specific.

For the resource layer from physical resources, then to virtualized logical resources, from virtual machines to now more lightweight container resources. As for the platform layer, it used to only talk about the technical platform, but now it is further divided into the business platform, which can also be understood as the middle platform layer that is more talked about at present.

At the same time, a service layer is added between the platform layer and the application layer to decouple resources and services.

If Internet of Things applications are involved, a network layer and a perception layer are generally added to the bottom layer. For example, the architecture diagram of a smart city standard platform and application is similar to the following:

The picture

In the platform + application construction mode, there is usually a separate service layer between the platform and the application to realize the opening of the external capabilities of interface services. Resources + services + applications are also commonly referred to as SOA layered architecture patterns, so the services layer can also be separated as a small layer.

The picture

Problem 1: Database and data layer

When building a complete overall architecture, there is no such thing as a data layer, which is what occurs when expressing the layered architectural implementation of a single application system.

It is also wrong to list structured databases, unstructured data, etc. in a separate layer in the general architecture diagram, which should be reflected in the technical architecture.

Another is to separate out a data layer and list large public basic data, such as the smart city architecture diagram mentioned above. If these basic data are provided upward with common capabilities, they can be summarized into the PaaS platform layer, and a data platform domain can be separated in the PaaS platform layer to reflect them.

Problem 2: Service layers and services

During the construction of the overall architecture, an open platform or service layer of capabilities can be developed separately, but specific business service capabilities need not be reflected. Because the nature of the separate business service capability has been the content of the application layer, that is, the application is refined and split into the business center and the foreground application, the service between the link. We can refer to another composition on the Internet, as follows:

This composition is not like a layered architecture in cloud platforms, nor is it like a layered architecture in application functionality implementations. You can actually see that if you embody a separate support layer, the support layer already resembles the business middle stage and capability provision that is often talked about today.

Then the whole architecture should be composed for the technology platform + medium platform + application mode.

SOA layering: component-service-process

For SOA architecture layering, the focus is on services. For components themselves, the concept belongs to the logical resource layer, while for services, the capability abstraction exposed by resources.

The picture

The key point of SOA architecture layering is to reflect the independent service layer, not draw the service bus, which can be drawn separately to provide specific business service capabilities, technical service capabilities. In the development of SOA architecture, the overall business system is divided into 4 components, 10 types of service domain, 5 types of process, so the focus of construction is to reflect the above components, service domain and process class. For composition with reference to SOA architecture, refer to the following:

The data layer here is best changed to a standard component layer, closer to the SOA architecture model. The service layer in the figure already shows individual API service interfaces. If the service interface data is large, it is generally divided into service domains, such as user center services and procurement services. In this way the composition reference is as follows:

In the figure above, cloud and SOA are combined together. The service layer in the figure above can actually be understood as the integration of component resource layer and service interface layer. A better way to visualize this would be to split it into a standard mid-stage resource layer – service layer – application layer.

Cloud and SOA architectures converge

Note that the cloud layered architecture emphasizes the three-tier architecture of infrastructure, platform and application. For SOA architecture, the three layers of resources, services and applications are emphasized. The construction of traditional application systems generally includes IT infrastructure, technology platform, database, middleware and applications. And then the layered architecture of the application system itself may be the standard three-tier architecture pattern.

These architectural layering approaches help us further integrate the layered architectural pattern.

There are many ways to layer architecture, including infrastructure layer, platform layer, component layer, support layer, service layer, application layer, data layer, presentation layer, etc. Multiple distributions lead to ambiguity and ambiguity in the layered model.

Here we talk from two levels of technical architecture and application architecture. The technical architecture follows the three-layer model of cloud computing. As for the application architecture, eTOM model is adopted as the standard resource, service and application three-tier model. Then the fusion of the two layered architecture models is a complete layered architecture model of cloud and SOA fusion.

That is, among the three layers of cloud computing, each layer itself can be further divided into three layers of resources, services and applications.

Take the IaaS layer as an example, the lowest layer of physical resources, such as virtual machines, belong to the resource layer. The IaaS layer provides API interfaces as technical services to open capabilities, that is, the service layer. Finally, based on resource capacity, a public oriented operation service platform of public cloud is constructed, which itself belongs to the application layer. For the SaaS layer, the underlying business components are resources, the abstract API interface is the service layer, and the final front-end business or process is the application function realization.

Application architecture layering

Back to the architectural layering of individual applications, the most talked about pattern is often referred to as the three-tier architecture pattern. In software architecture, the classical three-tier architecture consists of the User Interface Layer, the Business Logic Layer and the Data Access Layer from top to bottom.

In the whole implementation process, a separate Facade layer may be added, or a separate API interface service provider layer, a unified DTO data transfer object layer, etc., but these do not affect the overall three-layer logical structure.

The three-tier architecture itself also corresponds to the complete realization of a business function, processing data acquisition and persistence operations in the data access layer, processing business rules in the business logic layer, and corresponding front-end display and user interaction in the interface display layer. When it comes to domain modeling, hierarchical architecture in domain model is introduced as follows:

The domain-driven design is further improved on the basis of the classic three-tier architecture by introducing a new Layer, the Application Layer, between the user interface Layer and the business logic Layer. At the same time, the naming of some layers has changed. Changing the name of the business logic Layer to the domain Layer is natural, while changing the name of the data access Layer to the Infrastructure Layer breaks through the limitations of previous database management systems and expands the scope of this basic Layer responsible for encapsulating technological complexity.

Of course, there are also technical architectures that combine domain model and traditional three-architecture ideas as follows:

The picture

Domain layer and business logic layer

A core of domain modeling is the domain model, which is no longer a single database table or data object, but a business object or domain object. Therefore, domain layer is designed and implemented for domain objects, and business rule capability itself is also a capability interface provided by domain objects. That is, business rules themselves are capabilities exposed by domain objects.

Traditional business logic layer implementations usually have a data object corresponding to a DAO, a Service, and an Interface. The DAO can be separated under the domain model, but the Service logic layer should assemble and aggregate the capabilities of the DAO layer according to the domain model.

Split the application layer independently

In my original understanding, the domain layer provides domain model and domain service capability interface, while the application layer further assembles and arranges the service capability provided by multiple domain object models of the domain layer, and then exposes it to front-end applications.

When it comes to the concept of application layer, it can actually be understood as the further sinking of common capabilities existing in front-end applications. That is, the application itself is only the bearer of the user’s business function realization, but the realization of this function can be presented in a variety of front-end forms, such as traditional CS desktop application, BS application, or mobile APP.

In e-commerce, a commodity order is an independent application. Users can complete it in APP or BS, but the capability provided by the final application layer should be the same regardless of where they complete it. For example, completing a commodity order requires simultaneous delivery and coordination with the underlying order, inventory and payment services. Obviously, this logic is not suitable for repeated writing and development in both BS side and APP side applications. This content should be implemented at the application layer.

Going back to microservices and mid-platform architectures, this application layer split is even more necessary, with the application layer sinking common service composition and assembly logic that should not belong to any one front-end application.

Interface layer or interface layer

In the development of a converged micro service module, it can be seen that the micro service module itself does not have an interface presentation layer, so the top layer of the micro service is only the interface service layer that provides API interfaces.

The API interface service capability can be provided to both APP front-end and BS end.

Software technology architecture layering

Software technology architecture composition, layered software can still follow the three-layer layered model, the focus is to clarify the key technology components or technical service capabilities used by each layer. For example, the technical architecture of the three-tier software development model is layered as follows:

If it is a technology platform itself, similar to a big data platform, we still need to consider stratification first and then explain the technical content of each layer in detail in the overall composition.

For example, if there is a big data platform, including big data collection, big data storage, big data processing, big data analysis and application, then this is the key layer, and the key technology adopted by each layer can be considered based on this layer.

For the technical stack composition can also refer to the basic technical architecture composition mode.

Technical architecture focuses on what key technologies, open source products or tools you will use to design software architecture. You can specify specific technical products or just product types.

For example, message-oriented middleware, you can specify RabbitMQ or just message-oriented middleware in your technical architecture.

The only similarity between technical architecture and software functional layered architecture is the layered architecture. Technical architecture has no specific business function points and implementation content in each layered architecture, but only key technical points.

Functional architecture of a single application

Note that the application functional architecture is completely focused on describing the functions of the application system, and does not care what three-tier technical architecture is used to implement a function. Therefore, the functional architecture should not reflect the data layer, the logic layer, and the technical points.

So how do you layer the functionality of an application?

We can refer to the hierarchical classification of business, which can be divided into basic support layer, executive layer and decision-making management layer. Thus comes the basic layering pattern upon which a functional architectural composition can be completed.

For a single application, you don’t usually have a cloud platform, a PaaS platform. However, the construction of a single application must have common technology support platform capabilities, such as their own process management, their common technology functional components, etc. Therefore, single application construction can also adopt the basic technology support layer + application layer + portal layer for composition.

The application layer is further subdivided by specific business domain or business phase.

Hierarchical composition logic for architecture diagrams

The core layering logic of different types of architecture drawings is basically given above. It can be seen that when composing an easel, composition methods in different scenes should not be mixed, otherwise the overall architecture drawings will be confused.

When drawing the overall architecture, it is generally necessary to focus on the composition mode of cloud three-tier architecture and SOA three-tier architecture. In the refinement of an application system, it is still necessary to distinguish whether to build a technical architecture diagram or a functional architecture diagram. The hierarchical logic of the two is also very different and cannot be mixed.

Composition logic for an architecture diagram

To complete an architecture composition, split it into sides + middle. Both sides are generally put specific standards, norms, such as safety management, quality management, technical standards and norms, development operation and maintenance norms.

The middle is where the emphasis is on layering.

The middle section, also discussed earlier, focuses on the architectural layering logic of cloud computing and SOA. Generally speaking, the core is the resource layer, platform layer, application layer and portal layer. The application layer itself can be further divided into service domains, or divided into multiple phases based on the value chain or service life cycle.

Under cloud and SOA, more emphasis is placed on platform + application building pattern.

Between the two is generally the service layer, through the SOA platform or API capability open platform to unified access and release services, in order to form a complete resource + service + application loose coupling architecture. At the same time, a complete architecture itself is multi-perspective, as follows:

Functional architectures can often be seen by specific users and business people, while technical architectures are often discussed by internal team developers. The architecture diagram designed to resources and platforms is often an important reference for operation and maintenance engineers to build deployment architectures. Therefore, the hierarchical attributes of different dimensions cannot be used together at will, resulting in the confusion of the architecture diagram.