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

I. background

Under the traditional mode, the business activities of enterprises will produce a large amount of business data. Financial personnel need to carry out accounting and output financial data according to business data. Through these financial data, enterprises can carry out financial management, financial analysis and business decisions. However, the workload of accounting is very large, and most of the work is relatively basic and simple, and can be replaced by computers. Enterprises spend a lot of human resources on basic accounting every year, and have no time to pay attention to more important financial management, financial analysis and business decisions. In order to solve this kind of problem, the financial center came into being. The financial center is the bridge between the business system and the financial general ledger system. By collecting all the business data, screening, accounting and conversion, the financial data are automatically generated and introduced into the financial general ledger system to save a lot of accounting labor costs. In addition, financial personnel do not need to switch back and forth between business systems to check business data. The financial middle station gathers all the financial data, and the financial staff can check the data and accounting work on a unified workbench, without the need to operate across multiple systems. Through the financial center, the integration of industry and property can be easily realized, and the financial personnel can liberate the productive forces and produce higher value. II. Financial Central Taiwan Business structure 2.1 overall retail business structure

The overall retail business structure is divided into foreground business, headquarters in Taiwan, enterprise / business background.

The front desk business is characterized by rapid change, great difference, detailed experience, cross-platform and multi-contact. The front desk business helps merchants integrate as many retail channels as possible to meet the needs of customers' shopping, entertainment and social experiences. In terms of structure, the central desk of the headquarters is a series of foreground business and backstage business, based on the core business scene of retailers, to establish core functions such as membership, transaction, marketing, operation, finance, data and so on. Headquarters Central Station does not directly provide application services for businesses and consumers, its main responsibility is to collect all business data, cooperate with various business units, refine the common needs of business, and support the rapid development of front-end and back-end business. Through the central station of the headquarters, businesses can track and accumulate the data of consumers' shopping channels and the whole process, interact with consumers in a timely manner in this process, grasp the changes of consumers' decision-making in the purchasing process, and give consumers personalized suggestions to improve the shopping experience. Then rely on big data, to achieve accurate marketing, intelligent recommendation of goods; intelligent procurement of products more suitable for sales; do a good job in financial management, continue to improve the efficiency of the use of funds. The enterprise / business background includes basic business, such as purchasing, supply chain, raw material control, manufacturing, contract management, joining agent, financial ledger and so on. Some of the business may be completed by the merchant's ERP system, so the headquarters China Central Station and the ERP system will do a good job of data docking, and the merchant's ERP system can still be used. The financial center is a part of the headquarters center, which automatically generates financial data by collecting all the business data, screening, accounting and conversion. At the same time, the financial middle station refines the common services related to finance, supports the rapid development of front-end and back-office business, and helps businesses to do a good job in financial management, financial analysis and business decisions. 2.2 Financial Intermediate Business structure

The financial center gathers data such as omni-channel sales, supply chain, assets and marketing promotion to automatically complete accounting and generate corresponding financial data. At the same time, the financial center can further dock the enterprise's financial ledger; provide standardized open capabilities for other system integration; provide partners with services such as expense reconciliation; provide original data for data reports and process financial statements, provide strong support for financial analysis and business decision-making.

Third, financial application architecture 3.1 what is the application architecture? The application architecture defines which logic modules the system consists of and the relationship between the logic modules, also known as the logic architecture diagram. The application architecture plays the role of a connecting link between the preceding and the following. On the one hand, it undertakes the landing of the business architecture, on the other hand, it affects the technology selection. 3.2 how to design the application architecture? To design the application architecture, we must first clarify the granularity and level of the design, in different granularity and level, the focus is different. Retail business is extremely complex, especially for this complex business, detailed analysis and design should be carried out layer by layer from macro to micro to ensure the order and consistency of the overall architecture. If you do not do so, it is easy to get the product technical team into chaos, which in turn greatly reduces the efficiency of team communication and collaboration. Here, the granularity and hierarchy of design elements can be considered in combination with the C4 model proposed by Simon Brown. From top to bottom, Simon Brown divides the entire software system into four levels, namely, system context (System Context), Containers (container), Components (Components), and Classes (class), which are described below. System context: is the highest level of abstraction and represents a component that provides business value. A system consists of multiple independent containers. Container: a component that can execute components or reside data within it. As part of the entire system, containers are usually executable files, but not necessarily separate processes. Components: can be thought of as a logical group of one or more classes. Components are usually composed of multiple classes under higher-level constraints. Class: in an object-oriented world, a class is the smallest structural unit of a software system. 3.3 Financial middleware application architecture design, how should the financial middleware system be designed at the above four levels? 3.3.1 the design of the system context level is first of all the system context level, which focuses on the relationship between the system to be designed and other systems. The design of the financial center system context is shown in the following figure. 3.3.2 Container level design is followed by container level, which magnifies the whole system and pays attention to which containers are made up of internal containers in the system. Containers are basically equivalent to the concept of bounded context. The demarcation of boundary context is a part of the strategic design of DDD, and it is the core design work. It is necessary to identify the boundary context at this level, which will play a key role in the landing of subsequent micro-service architecture. The above picture shows the application architecture diagram in the financial center system, which adopts the hierarchical architecture model. The concepts of the application layer, domain layer, infrastructure layer and DDD in the diagram are the same, but they are the hierarchical logic under the container level, and the perspective is within the whole system. For a single system, the application layer and domain layer logic will be relatively simple, usually merged into a micro-service deployment, and there will not be a very clear demarcation of the boundary context. However, for enterprise systems, the business logic is very complex, and many bounded contexts with single responsibilities and complete functions will be divided internally to ensure that the system architecture evolves healthily and orderly. Application layer: the application layer is a very thin layer, and the services in the application layer correspond to a business use case with business value. It is mainly responsible for composing and orchestrating domain services, dealing with the order of execution and the assembly of results in business use cases, and providing services to the access layer through the API gateway. The container-level application layer involves the logic of the whole system and usually contains several cheap bounding contexts, and their internal business logic will not be very complex, but because it is directly oriented to users, in order to cope with the rapidly changing external requirements, the application layer changes very frequently, and it realizes the rapid adaptation of business processes through the composition and orchestration of domain services. For example, the settlement management shown in the figure above is an application layer bounding context, which provides application services related to settlement management for the access layer. It realizes its own application service capabilities by combining and arranging the domain services of accounting domain, settlement domain, payment domain and other business systems in the domain layer. Domain layer: domain layer is a very thick layer, which is the core of business software, including domain objects, domain services and the relationship between them, and is responsible for expressing business concepts, business status information and business rules. Domain-driven design advocates rich domain model, that is, business logic is attributed to domain objects as far as possible, and the parts that cannot be attributed are defined in the form of domain services. The needs of users often change, but the changes are always regular. changes in user experience, operation habits, market environment and management processes often lead to changes in interface logic and application logic, but the core domain logic does not change much. so the business logic of the domain layer is usually common and stable. The container-level domain layer involves the logic of the whole system and usually contains multiple bounded contexts, which provide the basis for the micro-service splitting of the whole system. Infrastructure layer: it provides general technical capabilities to other layers, such as distributed communication capabilities, persistence capabilities, message communication capabilities, task scheduling capabilities, etc. 3.3.3 component level design is again the component level, which magnifies a single container, and a component is a logical group of one or more classes that jointly perform a class of responsibilities. At this level, we will focus on how the container is layered and what logical components are contained in each layer. The image above shows the application layer container architecture, which also uses a hierarchical architecture, including interface layer, application layer, anti-corrosion layer and infrastructure layer. The interface layer defines the service protocol (API) provided to the upper layer, and the user of the interface layer is usually the presentation layer. The application layer here is more fine-grained, within the container, or tactical level. Depending on the complexity, it usually contains one or more application services and business components with bounded contexts. Each application service implements a business scenario or business use case by orchestrating services in other bounded contexts. The anti-corrosion layer is used to integrate with other boundary contexts, and inside the anti-corrosion layer, you can transform your model with the external model to prevent it from being contaminated by the external model, thus making the internal logic unstable. When the external model or interface protocol changes, only the anti-corrosion layer logic needs to be modified, which will not affect its own business logic. There is usually no domain model in the application layer container, so there is no need to access the database, because it is mainly composed and choreographed logic. if there is a concept similar to the domain model, it is necessary to analyze whether part of the domain logic is leaked to the application layer, and consider sinking the domain logic to the domain layer to ensure the unity of responsibilities of the application layer. The image above shows the domain layer container architecture, which is divided into interface layer, application layer, domain layer, anti-corrosion layer and infrastructure layer. The interface layer defines the service protocol (API) provided to the upper layer, and the user of the interface layer is usually the application layer container. The application layer provides external service capabilities by arranging domain services, domain models and a small number of external services. A small number of external services are emphasized here because the business logic inside the domain layer container is usually common and stable. It will only rely on more basic and stable service capabilities, and rely on as few external services as possible. Only in this way can we ensure that the business logic inside the container is common and stable. The domain layer here is more fine-grained, within the container, or at the tactical level. The domain layer contains a variety of domain models, such as domain entities, aggregation roots, domain services, warehousing and so on. As a connecting component of the domain layer and the infrastructure layer, warehousing does not need to pay too much attention to the storage details. In the design, the warehousing interface is placed on the domain layer, and the specific implementation of the warehousing is placed on the infrastructure layer, and the domain layer accesses the data storage through the interface, without paying too much attention to the details of the warehousing data. This makes the domain layer pay more attention to domain logic. The core of the domain layer container architecture is the domain layer, which contains the core business model and business logic, which has nothing to do with the specific technical framework and only focuses on the business itself. The domain layer is the place where domain knowledge is deposited. It is the basis and bridge for communication between business personnel and technical personnel. 3.3.4 Class level design is finally the class level, which is the smallest module built by the system. This level pays attention to which classes are to be designed in the component, what is the responsibility of each class, what is the relationship between classes, and the class level is partial to detail. I will not expand in detail here. Fourth, micro-service architecture design micro-service architecture, is a way of technical architecture. It builds the application into a series of small autonomous services divided by business domain. Microservices are seen as the future, and they can be upgraded and expanded more easily by breaking applications and services into smaller, loosely coupled components. More and more Internet companies use this architecture to deploy their systems, and likes are no exception. Micro-service architecture has many benefits: splitting large single applications into multiple micro-services to solve complexity problems. Each microservice can be developed and maintained by a dedicated team. Each microservice can be deployed and expanded independently. Micro-service architecture also has many shortcomings: micro-service architecture is a distributed architecture, which will bring the inherent complexity of distributed architecture. The problem of data consistency caused by database partition. It becomes very troublesome to test an application system based on micro-service architecture. In fact, the micro-service architecture is more about the scope of technology implementation and operation and maintenance deployment. How to split the micro-service, the micro-service architecture can not give the answer. This needs to use the design results of the application architecture. As mentioned above, the container is basically equivalent to the concept of bounded context, and the division of bounded context plays a very important role in guiding the splitting of micro-services. A micro-service generally contains one or more bounded contexts. How to define how many bounded contexts a micro-service needs to contain? First, it will be judged according to the business complexity of the bounded context. If the complexity is very high and maintained by multiple developers, it will generally be deployed as a micro-service and evolve independently. Second, it will be judged according to the technical complexity. For example, there are scenarios with high concurrency, high availability and stringent performance requirements in this business domain, and special technical architecture is required. Usually, separate deployment will be considered, which is physically separated from other boundary contexts. Micro-service architecture needs to follow the principle of gradual evolution. Multiple bounded contexts are usually deployed in one micro-service at the beginning, and then gradually split into multiple micro-services with the increase of business complexity and technical complexity. Breaking up micro-services into small pieces at the beginning will bring a lot of inherent problems of distributed architecture, which may be bothered by distributed problems before the business is developed. The following describes how the micro-service architecture of the financial center has evolved.

At first, the business is relatively simple. In order to facilitate deployment and maintenance, as shown in the figure above, all bound contexts will be deployed to a micro-service to provide services, but problems will soon be encountered. The business will become more and more complex and will have dependencies with other systems. For example, the purchase, sale and storage scenario of the supply chain system will trigger the accounting business of the financial center, the financial center needs to rely on the inventory documents of the supply chain system for accounting, and some scenarios of the supply chain also need to rely on the ability of the financial center, which leads to circular dependence on deployment. when the two sides of a project depend on each other, there is a problem that the release order cannot be determined. Forced press release caused some functions to be unavailable for a period of time during the release period and could not make a smooth transition.

In order to solve the problem of smooth release, the application layer and domain layer can be physically isolated and deployed separately. Take the supply chain system and the financial middle platform system as an example, from the perspective of business positioning, the supply chain is the upstream business of the financial center, and the core business logic of the supply chain does not depend on the financial business at all. therefore, the boundary context of the supply chain domain layer does not depend on the boundary context of the financial middle platform domain layer. However, in some application scenarios, the application layer of the supply chain needs to arrange the data of the financial center to be displayed to the users, or trigger the business execution of the financial center. In this case, the application layer of the supply chain only needs to rely on the domain layer of the financial center. Therefore, if the release order is released in the order of 1, 2, 3, and 4, the problem of circular dependency on deployment will no longer occur.

With the outbreak of business volume, different bounding contexts face different levels of access. For example, accounting domains need to deal with high-concurrency business document accounting, need to solve technical problems such as high concurrency and high performance, so accounting domains are separated and deployed as micro-services, so that they can be designed independently and expanded horizontally.

However, some bounded contexts can be deployed together as far as possible, such as settlement domain and bill detail domain, because once deployed separately, distributed transaction problems will arise, which will be very tricky. Real-world scenarios have also encountered micro-service split. Distributed transaction problems have not been well solved, and micro-services have been merged. Therefore, if you do not encounter the problems of high complexity, high availability, high concurrency and high performance, try not to split the micro-services into very fine, so as to prevent the business from not developing, but bring a lot of complexity problems inherent in the distributed architecture. Fifth, the definition of China Taiwan, DDD and Micro Services China Taiwan is derived from Ali's China Taiwan strategy (see Zhong Hua, edited by Zhong Hua, "the way of Enterprise IT Architecture Transformation: Alibaba's Strategic thinking and Architecture in Taiwan"). The essence of China Taiwan is to refine the common needs of each line of business and turn these functions into component-based products. What business the front desk wants to do and what resources it needs can directly go to the middle desk, and it is not necessary to change its bottom layer every time, but to obtain business capability support on the basis of a richer and flexible "large and medium-sized platform", so as to make the "small front desk" more flexible and agile. The middle platform architecture is considered to be the direction of the enterprise architecture in the future. Zhongtai, DDD and micro-services belong to different levels of content. Zhongtai architecture is an enterprise-level architecture model, which is a panoramic architecture from the overall and overall perspective of the enterprise. DDD is a set of design ideas to deal with complex business, in which the application layer, domain layer, application services, domain services and many concepts in the middle platform come down in a continuous line. Micro-service is the category of technology implementation and deployment, and it is the technical tool of landing platform architecture. A picture to express their relationship:

Sixth, this paper summarizes the practice of the middle platform architecture of Youzan retail finance, and introduces the architecture process of the complex business system in detail. firstly, based on the overall business architecture, the application architecture of the system is designed, and the application architecture has different design granularity. We can refer to the C4 model to carry out the design work step by step from the macro perspective to the micro perspective. Then, the partition of the bounded context based on the application architecture can guide us to split the micro-service. By judging the complexity of the bounded context, it is more appropriate to divide it into several micro-services. Finally, the relationship between CCTV, DDD and micro-service is introduced. Through this article, I hope to provide some reference value for developers in architecture design.

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.