Reading Notes of "China-Taiwan Architecture and Implementation"

Reading Notes of "China-Taiwan Architecture and Implementation"

1. Building enterprise-level applications based on the microservice architecture has become an industry trend. The microservice architecture has achieved application decoupling very well, can better pool applications to the cloud, and solve the problems of single application expansion and insufficient elastic scalability.

2. As a middle platform, it is necessary to deposit general business capabilities into the middle platform business model to realize the reuse of enterprise-level business capabilities.

3. DDD first divides the boundaries of the business domain manually from the business domain, and adopts the event storm workshop method to analyze and extract domain objects such as entities, value objects, aggregate roots, aggregates, and domain events in the business scenario. The domain model is used as the input of microservice design, and then the detailed design of microservice is completed. Microservices designed with the DDD method have very clear business and application boundaries, conform to the design principle of "high cohesion and low integration", and can easily adapt to model changes and microservice architecture evolution.

4. Table of contents

   • This book mainly includes 24 chapters, is divided into 6 parts in all.
     The first part is to understand the middle platform (chapters 1 to 4).
     This part includes 4 chapters, mainly introducing the background knowledge of the middle platform, knowing and understanding the true meaning of the middle platform, from the business center, data center, technology center and related The matching organizational structure and other aspects analyze the capabilities that traditional enterprises should have in the transformation of the middle office, and take you to a preliminary understanding of how DDD guides the design of the middle office and microservices, and clarifies their collaborative relationship.
     The second part is the basic principles of DDD (chapters 5-11).
     In order to allow you to understand DDD more deeply, this part uses some easy-to-understand cases to help you learn and deeply understand the core basic knowledge and design ideas of DDD principles. and methods, etc., 'understand the collaboration and dependencies between them, and solve the difficult problem of understanding the DDD concept', and prepare for the practice in the middle and Taiwan. This part includes 7 chapters 'mainly explaining the key core knowledge system of DDD, including domain' subdomain, core subdomain, general subdomain, supporting subdomain, bounded context 'entity' value object, aggregation' aggregate root, domain event and DDD Layered architecture and other knowledge.
     The third part is the domain modeling and microservice design of the middle platform (chapters 12 to 19).
     This part includes 8 chapters, mainly introducing how DDD builds the business model of the middle platform through strategic design' and how to guide microservice splitting and microservice design through tactical design. Designed. In this _ part, I will use multiple actual cases to take you through the whole process design of the middle platform and microservices with the DDD method, deeply understand the steps and methods of DDD in the middle platform domain modeling and microservice design, and design ideas and value.
     l) Understand how to build a domain model with the event storm method.
     2) Understand how to use DDD design ideas to build an enterprise-level reusable middle-end business model.
     3) Understand how to use DDD to design microservice code models, how to map domain models to microservices to establish the mapping relationship between domain models and microservice code models, how to complete the evolution of microservice architecture, etc. Finally, a case is used to connect all the knowledge points of DDD together, and take you to understand how to use the design method of DDD to complete the whole process of domain modeling and microservice design, and analyze and explain the code examples in detail.
     The fourth part is front-end design (Chapter 20 and Chapter 21).
     This part includes two chapters 'mainly introducing the design idea of ​​micro front-end, through the design idea of ​​front-end micro-service and unitization' to solve the front-end application solution after the construction of the business center is completed. It is difficult to integrate the pot and front-end and back-end services. The book explains how to learn from the design idea of ​​microservices to deconstruct the front-end application "realize the dismantling of the front-end application" and introduce the transformation strategy and technology implementation of the front-end architecture in combination with practice. In addition, this part also discusses the unitized design method based on the domain model. The unitized design of the combination of microservices and microfrontends can not only reduce the complexity of enterprise-level front-end application integration, but also enable enterprises to have stronger product rapid release and business response
     capabilities. This ability can give our team a , R&D model, business capability release, etc. bring great
     value.
     The fifth part is the design case of the middle office (Chapter 22).
     This part includes a chapter, which takes you through the complete process of the middle office design through the insurance order design case "using a top-down domain modeling strategy". The case covers business domain decomposition, mid-stage domain modeling, micro-service and micro-front-end design, unit design, and how to achieve business and data integration. I hope it can help you deepen your understanding of DDD, mid-stage, micro-service and micro-front-end, etc. A comprehensive understanding of the knowledge system, design thinking and technical system can be better invested in the construction practice of Taili Microservices in DDD'.
     Part VI Summary (Chapter 23 and Chapter 24)
     This part is the summary of the whole book, including two chapters. The book combines my many years of design experience and thinking, 'Take you to understand the evolution strategy from a single application to a microservice architecture', 'How to avoid common misunderstandings in DDD design', 'Microservice design principles and key designs under a distributed architecture, etc.

5. Background: Enterprises, especially giant ones, when their business develops to a certain scale, often face the problem of a wide variety of businesses and high business dependence. And with the development of business, there will be more and more departments in the enterprise, and the division of labor will become more and more detailed. The dependence and communication costs between departments will also become higher and higher.

   
   If there is a lack of enterprise-level overall planning, the ability to respond quickly to market changes and the mechanism to efficiently support business model innovation , the cost of enterprise operations and innovation will increase significantly

   In order to improve market response capabilities and solve business model innovation problems, more and more companies have begun to try digital transformation
   .

6. Problems of digital transformation of traditional enterprises:

   In the past ten years, new e-commerce models such as mobile Internet and changes in customer consumption behavior and habits have greatly stimulated and affected the inherent business forms and business models of traditional enterprises. Traditional enterprises have moved from closed to open, learning from the successful experience of Internet companies, and began to actively integrate into the Internet business ecosystem. However, due to the long-term technical stagnation of historical [pumps due to 'traditional enterprises carry too much technical debt', the technical capabilities are seriously backward, and at the same time, the solid "departmental walls" between various departments in the enterprise, the 'gap between business and technology' It also
   brings considerable difficulties to the digital transformation of enterprises . On the whole, the digital transformation of traditional enterprises needs to focus on solving the following problems.

   • The problem of backward technical system
     Most traditional enterprises adopt a centralized architecture, the technical system is relatively backward, and the scalability is not strong. The centralized architecture relies too much on device resources, and most of them run on mainframes or minicomputers based on stability or performance considerations. At the same time, 'traditional enterprises mostly adopt the disaster recovery model of "two locations and three centers"' The high availability capability is not strong, it is difficult to achieve multiple centers and multiple activities, and it is easy to cause resource waste.
     In terms of operation and maintenance capabilities, it is too dependent on manual operations to achieve automatic operation and maintenance, and automatic elastic scaling cannot be achieved in the face of business scenarios with sudden high-frequency access. When the business volume reaches a certain scale, the capacity and profitability of the centralized database will easily become the bottleneck of business development.
     All in all, the traditional centralized architecture technology system has been difficult to adapt to the business development requirements in the new form
   • Problems with monolithic architecture
     Centralized monolithic applications tend to put multiple functions into one application, and over time, this application will become a large and complex 'monster'. With the replacement of project team members' Over time, few people can fully understand the logical relationship between these codes. Some people may prefer to add unnecessary codes because they are worried about modifying the legacy codes to cause unpredictable bugs, which will lead to application It is getting bigger and more complicated, the readability is getting worse and worse, and finally fell into a vicious circle. For the entire project team, the system development work has become an extremely painful thing. In addition to the code, the single application also
     has There are many problems. Due to the high integration of each module of the single application, it is likely that the entire single application is unavailable due to a local small bug. In addition, the deployment package of the single application is too large and difficult to implement on the cloud Elastic scaling of resources leads to poor application scalability and low resource utilization. At the same time, it is difficult to complete the technical upgrade of partial functions of "a single application as a whole". It is difficult for enterprises to try new technologies, so that technical capabilities = straight stagnation Without progress, technology upgrades cannot be completed in a timely manner, resulting in more and more technical debt.
   • The problem of backward R&D, leasing, operation and maintenance capabilities
     —generally, the project team of a single application has a large scale, and usually adopts the traditional waterfall development model. The disadvantage of this development model is that the development and testing cycle takes a long time, the delivery quality and cycle are difficult to guarantee, continuous and rapid delivery cannot be achieved, and the response ability to business needs and markets is relatively slow, and it is difficult to implement agile development.
     In addition, cloud computing platforms and automated operation and maintenance tools have limited ecological support for single applications, and the deployment and operation and maintenance processes of applications are relatively complicated. When there is a problem with the application, it is basically based on human inspection, and it is difficult for the R&D team and the operation and maintenance team to quickly locate and coordinate to solve the problem.
   • Duplicated IT Capability Construction
     In order to support internal business development, most traditional enterprises have built a single core system with a centralized architecture. In the past ten years, with the rapid development of Internet e-commerce business, many traditional enterprises have to maintain traditional business and develop new business for the mobile Internet ecosystem. Due to the fact that the traditional centralized technology system and R&D model are difficult to support the massive and high-concurrency business requirements of the Internet, in order to avoid the mutual influence between traditional core and mobile Internet applications, many enterprises adopt distributed technology system construction in addition to traditional core applications However, because the two sell homogeneous products, there is an intersection in the basic function module k, so there is a problem of repeated wheel creation.
     In addition to the repeated construction of traditional core applications and mobile Internet applications, the problem of business homogeneity has also emerged in different business scenarios or channels. These different channels with homogeneous business may also be the hardest hit areas for repeated construction.
     In addition, within the group, due to the lack of an overall plan for IT construction, the problem of repeated construction of public business capabilities (such as customers, etc.) among different subsidiaries may become more prominent.
     So many traditional companies have debates about "dual cores" or "stable and sensitive dual states". Then, why do such problems mainly occur in traditional companies, but not in new Internet companies? I think the root cause is:
     " It is difficult for the traditional technology system, R&D model and business model to handle the contradiction between traditional and mobile Internet business development at the same time. "
     To sum up, to solve the problem of repetitive IT construction, it is necessary to improve technical capabilities and restructure business model manpower to realize the reuse of enterprise-level business capabilities. This is also a problem that needs to be solved in the digital transformation of traditional enterprises.

7. Domain layer code structure

   • The leave microservice domain layer has two aggregations of leave and personnel. Leave and Ren Yuan codes are placed separately in the directory structure where the respective aggregates are located. If as the business develops, personnel-related functions need to be separated from the leave microservice, we only need to remove the personnel aggregation code directory as a whole, deploy it independently, and quickly release it as a new personnel microservice.

8. When designing and developing microservices, we must always think about the evolution of the microservice architecture, and we need to consider the decoupling of aggregation and the reorganization of aggregation in the future. After decoupling, the boundaries of microservices will be clearer, it will be easier to adapt to rapid changes in business, and the evolution of microservice architecture will be easily realized. Naturally, it will be possible to respond to changes in front-end business needs faster.

9. Example: Insurance order-based design under the China-Taiwan strategy. Deeply understand the core knowledge system and design ideas of DDD-based Zhongtai construction