[Yuan Chuang Conference Preview] 1024 Programmers’ Day (two days before), meet at the Open Source China office, let’s talk about AI! >>>

1 Introduction

1.1 Architecture classification

In the field of software design, enterprise architecture is usually divided into the following five categories:

How to understand the basis of architecture classification and their relationship with each other? Business is the basis for the survival of an enterprise, so the business architecture is the foundation and the soul, and everything else is the support for the business architecture; the corresponding product architecture and data architecture are formed based on the business architecture; and finally implemented through the technical architecture.

Application architecture is used to subdivide product architecture and form products through application integration. However, the essence of the difference between application architecture and product architecture should not only be in the granularity. More importantly, the product directly undertakes the business and is divided according to the business problem domain; and the application needs to consider the accumulation and reuse of general capabilities to provide unified support for multiple products.

Business architecture: In the early stage of business requirements, fuzzy requirements are described into clear problem domains, mainly including business planning, business modules, and business processes.
Product architecture: Born out of business architecture (mainly business processes and business modules), it focuses on the enumeration and classification of functions.
Data architecture: From the perspective of problem definition, logic (process) + data are the two cores. While business architecture analyzes processes, another core is to define data architecture and combine processes and data to form products. In practice, the work of data architecture is often placed within the product architecture or application architecture. From a global perspective, this is a misunderstanding. Data is a valuable asset of the enterprise, and the quality of its architecture directly affects the competitiveness of the enterprise. It must be considered and considered holistically. design. Data architecture needs to solve two key questions - 1. What data is needed 2. How to store the data.
Application architecture: The application architecture is used to subdivide the product architecture, conduct more fine-grained problem disassembly and division of responsibilities based on the product architecture, and extract reusable modules to form basic capabilities. The closest implementation of application architecture.
Technical architecture: The above four architectures start from the perspective of problem definition, and the technical architecture starts from the perspective of problem solving, focusing on technology selection, development framework, development language, etc.

1.2 SOA

Since the end of 2019, my work has focused on the construction of middle-end products in the supply chain field. An inevitable key word in the construction process is servitization. Different people will have different views on this. Personally, I have different views on servitization. Understanding is more inclined to SOA, so let’s talk about the understanding of SOA through this article.

As an architectural style, SOA is more of an ideological system of business architecture from the perspective of architecture classification. It can be used as a methodology to guide us from the definition of the business model to the implementation of the overall business architecture. SOA emphasizes our thinking and design on the nature of business, and continuously traces, abstracts, summarizes, summarizes, and deduces the nature of business through co-creation (method rather than form) to improve business flexibility, accelerate business innovation, and improve business Efficiency; business architecture should not be skipped and treated as an application architecture or technical architecture term. Often when talking about servitization, many practices will use technical frameworks (platforms) to equivalently replace the concept of servitization, and pursue the implementation of hot technical frameworks (such as serverless and codeless) in existing systems as an integral part of the system. The main theme of service-oriented construction, such construction often ends up with poor results. The reason is that the use of technical frameworks is just a technique and a tool, while the essence of service-oriented (SOA) is Tao and method.

Software architecture has not yet undergone revolutionary breakthroughs after SOA was proposed. Many architectural ideas, such as EA layered architecture, microservice architecture, DDD architecture, etc., are mostly evolved and iterated from different angles based on the SOA architectural style. Therefore, this article is The process of elaborating SOA will have "shadows" of other architectural ideas to some extent.

2 Look at SOA from three perspectives: What, Why and How

2.1 What

2.1.1 Terminology

The definition of any concept has its corresponding terminology.

Business behavior: An atomic behavior abstraction with certain business semantics.
Business process: an organic combination of a series of business behaviors that achieve specific business value (meet customer needs).
Business services: business behaviors or business processes that provide added value (it should be noted that business services can be either business processes or business behaviors, or even a combination of the two). Have clear business function definitions and value measures (SLAs).
Application component: A collection of application functions that are structured and packaged according to certain correlations (for ease of understanding, simplified and equivalent to business services without considering layering). To improve the consistency, flexibility and reuse of applications.
Application: An organic collection of application components used to provide business functions (single or multiple) and provide incremental value support for the entire system or platform. Jinghuizhong's demand planning, business planning, inventory planning, distribution and replenishment planning, and supply planning (there are also certain hierarchical concepts between applications, which are close to the understanding of the business essence).
System: an organic combination of a series of applications and services (some services can independently provide incremental value support for the system, which is reflected in many microservice architecture ideas), with end-to-end complete business functions, and systematically provide users with incremental value . The Jinghui product (supply chain planning product) I built is itself at the system level.
Platform: An organic combination of one or more systems, with a complete set of end-to-end business functions for the entire business line or business ecosystem. The goal is to provide overall business value for business lines or business ecosystems.
Architecture: represents the basic elements of a system. It is reflected in the set of elements that constitute the system, the relationship between elements, the interaction with the external environment, and the principles that guide the iterative evolution of the system.
Architectural style: A set of architectural definitions that share common characteristics and core principles.

2.1.2 Definition

SOA is an architectural style that is committed to using services with consistent business functions as the basic unit for designing, building and orchestrating combined business processes (or solutions).

2.1.3 Services

Services are the basic unit for designing, building, and orchestrating business solutions in a complete business entity.

Services can be defined from two directions: a service is an atomic unit (li) that provides business functions, and is managed through a service contract (table).

A service contract is a collection of all agreements between service consumers and service providers. It usually consists of the following elements:
Service interface: interface definition, describing what the service does, incoming and outgoing parameter definitions, etc., usually presented in the form of an interface document. Operates around a core business function and associated operations.

Service strategy: The implicit consensus between service parties, describing adaptation scenarios, constraints, etc.
Service level: The service itself is measured through various aspects such as service quality, availability, performance, etc. It is basically equivalent to SLA and includes two important aspects of service indicators - business indicators and technical indicators (technical indicators - RT, throughput, availability, Reliability, etc.; business indicators - the quality or degree of completion of completed business functions, such as whether replenishment suggestions meet business expectations (turnover and out-of-stock KPI).

The management attributes reflected in the service contract are the fundamental difference between services and other common definitions (modules, components, etc.). We use service contracts to manage the full life cycle of services (design, implementation, deployment, upgrade).

Service implementation - the realization of business functions is a mapping of the core essence of SOA.

Service implementation: There are multiple implementation methods [coding implementation | orchestration of other services | adaptation and encapsulation of existing applications | hybrid implementation]. How the service is implemented is transparent to the service consumer, that is, the service consumer only cares about the what of the service rather than how. Services can be changed in both horizontal and vertical directions while keeping the interface unchanged (horizontally providing different implementations according to different scenarios in different industries; vertically evolving services according to industry development).

2.2 Why

Why choose SOA? There are many opinions on this issue

Clear responsibilities (interface definition)
Flexible expansion (separation of interface and implementation)
Highly reusable
Interface classification
Highly manageable

None of the above points can be denied because they can be derived through service definition. The first three of them are all built for a single service. As long as you master enough technical means, you can easily create a service (single service). This is not the core competitiveness of SOA. The purpose of SOA goes far beyond the design and definition of interface technical details. The core focus is on the business content and connotation of services (rather than how to design and implement them). While using the techniques and tools summarized and refined by SOA, don’t forget the Tao and the Dharma. How to do is very important, it guides you to do something well; but what is more important, it guides you to do the right thing.

To deeply analyze the value of SOA, we need to return to the essence of SOA - committed to building business function-driven services within different business environments within the enterprise, and on this basis, assembling services into higher value/higher level businesses Process (Solution). Therefore, the value of SOA can be summarized into two key points:

Empower enterprises to build service collections with business value and complete business semantics;
Based on service collection, organize and orchestrate services to build agile & flexible business processes/solutions. [Agile services can be quickly adjusted and evolve independently; the business functions of flexible services are clearly defined (clear boundaries and strong cohesion) and can be flexibly combined]

2.2.1 Expression forms of SOA value

Consistency: Consistency is the core value of SOA, including data consistency and behavior consistency [data provides business consistent & consensus public data access services; behavior provides a unified entrance to the outside world (business processes, external tasks, etc.)]
Decoupling: Reduce the dependence and coupling between functions and data through separation. As independent business functional units, services can work together in the application system, and each has its own clear and independent business goals and life cycle.
Modularity & Agility: Provides a foundation for business modularization; at the same time, based on modular implementation, modules can be reused and flexibly combined in multiple business processes and scenarios, thereby supporting rapid business innovation.
High degree of manageability: The definition of service levels ensures that while supporting business goals, services can be managed beyond business function cognition (monitorable, optimizable, and adjustable).

2.3 How

Compared with What and Why, the practice of SOA is a huge problem. This article chooses to analyze it from the perspective of service design.

2.3.1 Sort out the context

For business systems, understanding the businesses we support and their core driving forces is the prerequisite for us to do a good job in servitization; if it is a platform system, we need to understand the mission of the platform given by the company's strategy and the ultimate goal, medium and long-term goals of the platform . In other words, the first step is to clarify the complete context of the servitization architecture. These contents need to be mapped into the model (models at each level, see layered design below for details). How to sort out the context, a good practice is to define the problem set. There is a view that asking good questions == half of the problem is solved. Problem set definition:

The context of the entire service-based architecture is described through the above eight questions:

Question 1-6: Describe the overall architecture requirements of the business/platform;
Question 7: Describe the conclusion of the architectural requirements review;
Issue 8: Service collection definitions are introduced. Service collection is the core achievement of SOA construction and needs to be understood from the perspective of continuous iterative evolution.

We reflect complete business semantics and platform semantics through service collections. How to determine whether a service collection has complete contextual semantics must be able to identify the following:

full context
Service Collection Scope of Responsibilities
Service grouping (reflecting service relevance)
Types and roles of services

Two main goals of service collection design

Provide a mechanism to identify the responsibility boundaries of a specific service and guide service implementation. (It is important to clarify service responsibilities and boundaries, avoid duplication of construction, and ensure behavior and data consistency)
Provide a mechanism to help understand the overall context of the service for more efficient service selection and service reuse. (Service classification, correlation between services)

Services in a service collection can be organized according to service types and service roles. Service types are described with reference to the service-oriented layered architecture. Service roles include task service roles, entity service roles, and decision-making service roles.

2.3.2 Service design principles

One of the keys to the success of SOA is to create a service collection with complete contextual semantics (business/platform semantics) so that different business processes and business scenarios can be supported by combining orchestration services. Service design issues in service-oriented architecture need to be considered across multiple or even all processes.

First of all, the easiest thing to think of is loose coupling. Whether it is SOA thinking or other ideas (egOOP), loose coupling is one of the basic principles; by reducing dependencies between services, it improves reusability in different application scenarios and isolates the impact of changes. Coupling - There are dependencies between services. First, let’s look at the two most important points for service:

Business functions provided by the service
The impact of services on business data

From the above two points we can easily derive two types of coupling (dependency) - data and functionality. There is a very basic question here about why dependencies are generated. From a technical implementation perspective, dependencies can be abandoned to implement a large and comprehensive service. Developers, especially those who are accustomed to object-oriented thinking, have developed an instinct for loose coupling/high cohesion, and rarely reflect on why they do this - two aspects (internal consistency guarantee; external capability reuse). Good service design not only focuses on reusability, but more importantly, provides consistency (behavior and data).

Again, how do you decide which services are available and what they are? Still starting from data and functions, we use functional decomposition and data isolation to determine what services there are and what they are. The basic principles derived from this extension are as follows:

avoid missing
avoid duplication
maintain consistency

How to implement the above principles? You can use the definition and transformation of problem sets:

2.3.3 Service collection design

We look at service collection design from three closely related aspects: layering, classification, and granular segmentation.

Service tiering

Information architecture is an important aspect that will be overlooked in the design of service-oriented layered architecture, reflecting the concerns of different roles in the enterprise.

Strategy and decision-making define the strategic direction and business goals of the enterprise, and guide the direction and outcome of the development of the enterprise's internal systems/platforms.
A business model describes in operating entity terms what is valuable to the business.
Business abstraction abstracts the business of a single business line or multiple business lines in an information-based way. Start with business abstraction and enter the problem domain definition.
The public semantic model adds service-oriented semantics based on business abstraction. The public semantic model describes business entities and information with consistent semantics shared among various business services on the platform, and requires consensus at the platform layer.
The subdomain domain model is an abstraction of the core business functions of each subdomain, including service definition and the definition of key entities in service implementation. From an overall perspective, it is a private model of each subdomain of the platform, and is not visible to the outside world except for service semantics.
The development implementation model is equivalent to the object model in OOP and is the cornerstone of development and implementation.

The relationship between business model and business abstraction

1-Business model describes the business process perceived by business operators; business abstraction not only describes the business process, but more importantly, abstractly describes the underlying business functions that the business process should include.
2-The business model describes all the important things for the enterprise's business; the business abstract describes the most fundamental content behind the things the enterprise's business wants.

Although the business model is the upper layer of business abstraction from a hierarchical structure, what the business model describes is the sample or instance corresponding to the business abstraction definition (conceptually, the scope of business abstraction is wider). Business abstraction is the abstraction and synthesis of business models. It must be carefully analyzed and summarized, and even deductively defined to define the fundamental content and structure hidden behind the main body of enterprise business operations.

The relationship between the common semantic model and the subdomain domain model

The common semantic model is used to describe the shared information of the platform layer service interface interaction, and is based on the standardized view model of the common data of all services under the complete business semantics of the platform. In short, the platform public semantic model defines the basic business service semantics at the business platform level. It is a unified language for the interaction between business services on the platform, platform business processes and platform business services, emphasizing unification and sharing. The subdomain domain model is a private model of each domain of the platform, which is used to drive the design and implementation of service functions in the subdomain. Unless there are essential changes in the business within the domain, the subdomain domain model needs to remain dynamically stable and isolate the erosion of external dependencies through the anti-corruption layer (the domain model is also the core of the DDD idea).

Service layering is the main body of service-oriented layered architecture design. A good way to understand the service layered architecture is to learn the TOGAF Meta-Model.

Business process (end-to-end): business operations performed in a sequence determined by certain business rules. High-level business functions usually span multiple application subdomains/business lines.
Business services (platform/system): highly modular business functional units. It is composed of different types of subdomain service combinations and can be used as an orchestration unit for business processes.
Subdomain services: Services provided by functional subdomains are visible to the platform and are used for the combined orchestration of platform business services. They can also be used as the basic unit for higher-level business process orchestration.
Subdomain basic services: Basic services used to support various functional subdomain services. They are visible to the subdomain but invisible to the platform. They are used for the orchestration of subdomain services.
Basic subdomain services: or called basic business domain services, provide basic business services on the platform and provide basic business functions and data services (eg merchant services, goods services, inventory services) for each functional subdomain or platform business services.
Infrastructure services: Provide infrastructure services shared by different levels (eg user management, rights management)

Model layering is an important complement to service layering. Service layering is clear and complete from a structural point of view, but it is not complete from the overall perspective of service-oriented construction. We need to add corresponding model abstraction.

Core model: The end-to-end business process carries the information model of the core value of the business. In the supply chain field, it is the document model, such as sales order, purchase order, and replenishment plan.
Public semantic model: defines platform-level business processes and business service interaction data. At the platform level or enterprise level, the common semantic model of interactive information in the end-to-end business process defines the complete business semantic entity definition required in the business process (each business semantic entity has clear boundaries and clear responsibilities). The core model is usually a subset of the common semantic model. The platform public semantic model includes a subset of external service entities of the lower sub-domain. According to the end-to-end complete platform business semantics, it can be organically integrated from the core entity subset shared by each functional sub-domain model of the platform to the platform, or it can be formed by the platform. A new definition of business model (combined from top-down and bottom-up directions). This model requires continuous iterative evolution, and many architectural decisions and improvements of the platform are based on this model.
Subdomain domain model: The domain model of each functional subdomain of the platform is used to drive the application system design and development of each functional subdomain. (The hierarchical description of the same service needs to maintain dynamic stability, and isolate external services through the anti-corruption layer to prevent external services from polluting the core business semantics in the subdomain, while keeping the business functions in the domain flexible and controllable. The subdomain domain model only uses its external service entities Visible to the outside world, others are invisible to the outside world.)
Cross-domain mapping model: used for each sub-domain domain model to achieve anti-corrosion dependence on external models.
Infrastructure service model: Provides a common infrastructure information model that jumps out of the hierarchy, such as user model and permission model.

Service classification

Service classification (or service role) is another important factor independent of scope of responsibilities and service granularity; it is used to identify the role that services play in composition/process orchestration.
If service stratification is a vertical segmentation, service classification is a cross-section. Drawing on the concepts of OOP and AOP, we use the architectural principle of separation of concerns to define service classifications.

Usually we define three major categories of services at a coarser granularity:

Task service: Task service usually implements a complete business function, which can be either a basic business function or a complex business function. This service type has a coarse granularity, ranging from independent subdomain basic services to platform business services that can have task service roles. Business services usually assume the role of task services. They are themselves a larger combination (process) of small-granularity services and can be designed to support one or more pending processes. Task services are highly targeted and have weak reusability. Usually, a service with tasks is an active service, which outputs value through active behaviors.
Entity Services: Services that manage access to business entities. For example, eg users, categories, products, and shopping carts. Entity services are typically independent of any specific business process and can be components of several different business processes. Entity services usually support task services by providing the required information to implement the task. Entity services usually have strong reuse potential.
Rules/Decision Services: Services that provide business decisions by executing business rules. For example, take the EG replenishment plan automatic review service. It is usually used to judge complex problems or support frequently changing business rules. In terms of granularity, rule/decision services are typically small to medium and are used to assemble larger services. Rule/decision services can be services at different levels (including business services, subdomain services, subdomain basic services, etc.), but they are more commonly used as basic services to support these services.

We provide flexible business capabilities by combining different types of service roles to support activities within business processes. Therefore, some basic principles are needed to help us reasonably combine services (reduce dependencies, limit coupling, and obtain maximum flexibility) - basic principles of service layering and composition:

The tasks of business processes are implemented through task services, and the core rules of business process routing are provided by rule/decision services.
Serving higher-level business services is composed of other smaller services
Task services can combine rule/decision services, entity services, and other task services
Entity services do not allow mutual calls
Services are one-way dependent. Upper-layer services can rely on lower-layer services and services at the same level. Lower-layer services cannot rely on upper-layer services.

Create new and different services (processes) through a rich collection of processes, entities and decision-making services; combine the flexibility of rules/decisions with the modularity and reusability of service layering to create an architecture for the implementation of system/platform practices Methodology.

Granularity segmentation

When we design services, a big doubt is what kind of granularity should our services be designed to? There is no unified standard for this problem. It can be solved by setting a combination of problem sets and combining service layering.

Who are service consumers (including potential consumers), eg other services, business processes, external partners
Where the service is consumed and through what path it is consumed (i.e. service topology)
Service performance requirements
Expected business scope and boundaries of services

In complex environments or systems (platforms), services have different types and granularities. A common way is to refer to the service layering for reasonable mapping:

Business process (end-to-end): spans the entire enterprise or multiple business domains of the platform, and is usually built from underlying services
Platform business services: The most coarse-grained services, providing highly abstract combined business functions to platforms or enterprises. The functions and data of business services are closely integrated with the business semantics required by business processes. Data integration services provide integrated data required for end-to-end business processes at this level.
Subdomain services: medium-grained services that provide business-related services for each business subdomain. They are used by different business services within the subdomain, but are not necessarily exposed outside the subdomain.
Subdomain basic service: the smallest granular service, providing low-level services to provide basic functional support for business functions in the subdomain
Basic subdomain services: finer-grained services that support the implementation of business functions of upper-layer business function services
Infrastructure services: More fine-grained services, independent of any business domain. (Clearly distinguished from business, eg security authentication, authority management, etc.)

3 Summary

The scope of architecture is too large and broad. This article attempts to explain my personal understanding from one point. There are too many related issues that I want to elaborate on, such as the combination of SOA and BPM, details encountered in the practice process, etc., but they have been deleted in order to analyze SOA more cleanly. I hope you readers will gain something.

Author: JD Logistics Cui Liqun

Source: JD Cloud Developer Community Ziyuanqishuo Tech Please indicate the source when reprinting

SOA Cognition and Methodology | JD Logistics Technology Team