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

This article mainly explains "how to understand the hierarchical model and composition of software architecture design". The content of the explanation in this article is simple and clear, and it is easy to learn and understand. let's study and learn how to understand the hierarchical model and composition of software architecture design.

Overview of Architectural thinking

For structural thinking itself, it is still a collection of many thinking modes, such as system thinking, structured thinking, programming thinking and so on. Since the core role of architecture is to build a bridge between the real world of business and abstract IT implementation, the core of architectural thinking is to understand business-driven technology, which serves the final business. To really achieve the balance between business and technology, requirements and implementation, software and hardware, static and dynamic, costs and benefits through architectural design.

As mentioned in previous articles, there are two key points in architecture design, one is decomposition and the other is integration.

Decomposition is the most basic, the focus of the architecture is to divide and conquer complex problems, while ensuring that each part of the decomposition can also be highly cohesive, loosely coupled, and finally integrated into a complete whole. The core of decomposition is to define the problem, so the architecture still needs to understand the requirements in the first place.

Integration is to cooperate with the actions completed by decomposition, and the components or subsystems that are finally decomposed can be integrated into a complete whole through appropriate interface design. Decomposition is only to speed up development and reduce the complexity of the problem. If the decomposed content can not be integrated together, then decomposition does not make any sense.

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

After the completion of the decomposition, a large system has been divided into many small modules, or the implementation of a small module itself is divided into multiple steps. Then the scattered nodes must be gathered and summed up to form a complete framework.

The key to the formation of this framework is to think in layers. Architecture layering is an unavoidable point to talk about architecture. through architecture layering, we can better understand the business system or function implementation in a better way.

Three-tier architecture of cloud platform: resource-platform-application

When planning a large architecture, we often refer to the standard three-tier architecture of cloud computing, namely, IaaS layer, PaaS layer, SaaS layer. For the IaaS layer, the focus is on IT infrastructure and virtualization; the PaaS layer focuses on building platform layer service capabilities; and for the SaaS layer, it is specific applications.

For the resource layer, from physical resources to virtualized logical resources, from virtual machines to now lighter container resources. As for the platform layer, it only talks about the technical platform, but at present it is further split into the business platform, which can also be understood as the middle platform layer, which is often said at present.

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

If applications such as the Internet of things are involved, the network layer and perception layer will generally be added at the bottom, such as a smart city standard platform and the architecture diagram of the application is similar to the following:

In the platform + application construction mode, there is generally a separate service layer between the platform and the application to open interface services to the outside world. Resource + service + application is also what we often call the SOA hierarchical architecture pattern, so the service layer can also be separated as a small layer.

Question 1: database and data tier

When building a complete overall architecture, there is actually no concept of the data layer, which appears when expressing the hierarchical architecture implementation of a single application system.

It is also wrong to list all the structured databases, unstructured data and so on into a single layer in the general framework diagram, which should be reflected in the technical architecture.

The other is to separate a data layer and list large public basic data, such as the smart city architecture map mentioned above. If these basic data have the common ability to provide upward, then it can be summarized into the PaaS platform layer, and a separate data platform domain can be divided into the PaaS platform layer to reflect.

Question 2: service layer and services

When building the overall architecture, we can create a separate capability open platform or service layer, but do not reflect the specific business service capabilities. Because the essence of separate business service capability already belongs to the content of the application layer, that is, the application is subdivided into the middle of the business and the foreground application, and the service connects in the middle.

We can refer to another composition on the web, as follows:

This composition is neither like the hierarchical architecture in the cloud platform, nor is it like the hierarchical architecture in the implementation of application functions. In fact, you can see that if you reflect a separate support layer, the support layer is already similar to the business platform and capacity provision that is often mentioned now.

Then the whole architecture should be composed by technology platform + middle platform + application mode.

SOA layering: component-Service-process

For SOA architecture layering, the focus is on services. For components, it belongs to the concept of logical resource layer, while for services, it is the abstraction of the ability to expose resources.

The focus of SOA architecture layering is to reflect an independent service layer, note that it is not to draw a service bus, here you can draw specific business service capabilities, technical service capabilities. When using SOA architecture for development, the overall business system is divided into 4 components, 10 types of service domains, 5 types of processes, then the focus in the construction is to reflect the above components, service domains and process classes.

For composition based on SOA architecture, refer to the following:

The data layer here had better be changed to the standard component layer, which is closer to the SOA architecture model. You can already see individual API service interfaces in the service layer in the figure. If the data of the service interface is large, it will only be divided into service domain, such as user center service, purchasing service and so on. In this way, the composition reference is as follows:

The cloud and SOA architectures are combined in the above figure, and the service layer in the above figure can actually be understood as the integration of the component resource layer and the service interface layer. A better way of composition should be split into the standard middle platform resource layer-service layer-application layer.

Cloud and SOA architecture convergence

Note that for the cloud hierarchical architecture, the emphasis is on infrastructure, platform and application three-tier architecture. For SOA architecture, it emphasizes three layers: resources, services and applications. The construction of traditional application systems generally includes IT infrastructure, technology platform, database, middleware and applications. And then the hierarchical architecture of the application system itself may be the standard three-tier architecture model and so on.

These architectural layering methods help us to further integrate the hierarchical architecture pattern.

There are many methods of architecture layering, including infrastructure layer, platform layer, component layer, support layer, service layer, application layer, data layer, presentation layer and so on. Multiple distributions lead to ambiguity and ambiguity in the hierarchical model.

Here we talk from the two aspects of technical architecture and application architecture, the technical architecture follows the three-tier model of cloud computing; for the application architecture, we use the eTOM model standard resources, services, application three-tier model. Then the fusion of the two hierarchical architecture models is a complete hierarchical architecture model that combines cloud and SOA.

In other words, among the three layers of cloud computing, each layer itself can be further divided into three layers: resources, services and applications.

Take the IaaS layer as an example, the physical resource virtual machines at the bottom belong to the resource layer, which provides API interfaces as technical services through the resource capabilities of the IaaS layer, that is, the service layer. Finally, based on the resource capabilities, a public cloud operation service platform for the public is constructed, which itself belongs to the content of 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 implementation of application functions.

Application architecture layering

Going back to the architectural layering of a single application, the most talked about is the commonly mentioned three-tier architecture model. In software architecture, the classic three-tier architecture consists of user interface layer (User Interface Layer), business logic layer (Business Logic Layer) and data access layer (Data Access Layer) from top to bottom.

In the whole implementation process, there may also be an independent Facade layer, or an independent API interface service providing layer, a unified DTO data transmission object layer, etc., but these do not affect the overall three-tier logical structure.

The three-tier architecture itself also corresponds to a complete implementation of business functions, dealing with data acquisition and persistence operations in the data access layer, business rules in the business logic layer, and corresponding front-end presentation and user interaction in the interface presentation layer.

When it comes to domain modeling, the hierarchical architecture of the domain model is introduced as follows:

Domain-driven design is further improved on the basis of the classical three-tier architecture, introducing a new layer between the user interface layer and the business logic layer, namely the application layer (Application Layer). At the same time, the naming of some levels has also changed. It is natural to rename the business logic layer to the domain layer, while changing the name of the data access layer to the infrastructure layer (Infrastructure Layer) breaks through the limitation of the previous database management system and expands the connotation of this basic layer which is responsible for encapsulating technical complexity.

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

Domain layer and business logic layer

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

Traditional business logic layer implementation is often a data object corresponding to a DAO, a Service and an Interface. Under the domain model, DAO can be separated, but the logical layer of Service should assemble and aggregate the capabilities of DAO layer according to the idea of domain model.

Independent application layer split

In my original understanding, the domain layer provides domain models and domain service capability interfaces, while the application layer is more likely to further assemble and orchestrate the service capabilities provided by multiple domain object models in the domain layer, and then expose them to the front-end applications.

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

In e-commerce, a product order is an independent application, which can be done in APP or BS, but the capabilities provided by the final application layer should be the same no matter where. For example, the completion of a commodity order requires simultaneous delivery and coordination with the underlying order, inventory, and payment of multiple services. Then this logic is obviously not suitable for repetitive writing and development in both BS-side applications and app-side applications. Then this content should be implemented in the application layer.

If we go back to the micro-service and mid-platform architecture, this application layer split is more necessary, that is, through the application layer to sink the common service composition and assembly logic, this logic and collaboration should not belong to any front-end application.

Interface layer or interface layer

When developing a micro-service module with aggregation capability, we can see 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 the API interface.

The API interface service capability can be provided not only to the APP front end, but also to the BS side.

Software technical architecture layering

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

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

For example, corresponding to a big data platform, including big data collection, big data storage, big data processing, big data analysis and application, then this is the key layering, based on which we can consider the key technologies used in each layer.

For the technical stack composition, we can also refer to the technical architecture composition pattern.

The key point of technical architecture is which key technologies, open source products or tools you will use in the process of software architecture design. It can be refined to specific technical products, or only to product types.

For example, message middleware, you can refine to use RabbitMQ, or you can only use message middleware in the technical architecture.

The only thing in common between the technical architecture and the software functional hierarchical architecture is layering. The technical architecture has no specific business function points and implementation content in each layer, only the description of key technical points.

Single application functional architecture

Note that the application function architecture completely focuses on describing what functions the application system has, and it does not need to care about what kind of three-tier technical architecture is used to implement a function. Therefore, the functional architecture should not reflect the data layer, logic layer, technical point of these contents.

So how to layer the functions of an application system?

We can refer to the hierarchical classification of business, and divide the business into basic support layer, executive layer and decision management layer. In this way, the basic hierarchical mode comes out, based on which a functional architecture composition can be completed.

Generally speaking, for a single application, there are no concepts such as cloud platform or PaaS platform. However, there must be common technical support platform capabilities for individual application construction, such as their own process management, their own common technical function components and so on. Therefore, single application construction can also be constructed by the way of basic technology support layer + application layer + portal layer.

The application layer is further subdivided according to the specific business domain or business stage.

Hierarchical composition Logic of Architecture Diagram

In the previous basic given the core hierarchical logic of different types of architecture, we can see that the composition of the easel should not be mixed with the composition of different scenarios, otherwise it will lead to confusion of the overall architecture.

When drawing the overall architecture, we generally need to refer to the cloud three-tier architecture, SOA three-tier architecture composition mode for composition. In the refinement to a certain application system, it is still necessary to distinguish whether to build a technical architecture diagram or a functional architecture diagram, and the hierarchical logic of the two is also very different and can not be mixed.

Composition Logic of Architecture Diagram

To complete a complete architecture diagram, you can first split it into two sides + middle. The two sides generally put specific standards and norms, such as safety management, quality management, technical standards, development and operation and maintenance norms, and so on.

The middle is where the focus needs to be considered for hierarchical construction.

We also talked about the architectural hierarchical logic of cloud computing and SOA in the middle part. Generally speaking, the core is the resource layer, platform layer, application layer, portal layer. For the application layer itself, the business domain can be further split, or it can be divided into multiple stage domains according to the value chain or business life cycle and then described.

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

The relationship between the two is generally the service layer, through the SOA platform or API open platform to uniformly access and publish services, in order to form a complete loose coupling architecture of resources + services + applications.

At the same time, a complete architecture itself is multi-perspective, as follows:

Functional architecture can often be shown to specific users and business personnel, while technical architecture is often discussed and used by internal team developers. The architecture diagram designed to resources and platform is often an important reference for operation and maintenance engineers to deploy architecture. Therefore, the hierarchical attributes of different dimensions can not be used at will, which leads to confusion of the architecture diagram.

Thank you for your reading. the above is the content of "how to understand the hierarchical model and composition of software architecture design". After the study of this article, I believe you have a deeper understanding of how to understand the hierarchical model and composition of software architecture design, and the specific use needs to be verified in practice. Here is, the editor will push for you more related knowledge points of the article, welcome to follow!

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.