CN113326028B

CN113326028B - Micro-service decomposition method based on domain-driven design and service panoramic event storm

Info

Publication number: CN113326028B
Application number: CN202110519086.9A
Authority: CN
Inventors: 贾子甲; 张贺; 吕骏; 李杉杉; 张玮
Original assignee: Shanghai Anchnet Network Technology Co ltd
Current assignee: Shanghai Anchnet Network Technology Co ltd
Priority date: 2021-05-12
Filing date: 2021-05-12
Publication date: 2022-07-01
Anticipated expiration: 2041-05-12
Also published as: CN113326028A

Abstract

The invention discloses a micro-service decomposition method based on field-driven design and a service panoramic event storm, which comprises the following steps: step S200, a business panoramic event storm workshop stage, preparing workshops, identifying field events, identifying key business objects by participants, identifying key events, dividing limit contexts, and identifying context mapping. The method can provide a micro-service splitting method of the software system with complete theoretical system and definite implementation steps, provides detailed description for each implementation step of the micro-service splitting method, provides reliable support for micro-service architecture decision of the software system, reduces time and labor cost for developing a micro-service decomposition design process, improves transparency of the design decision process and objectivity of a decision result, and accords with the current and future scenes for designing the software system based on the micro-service architecture.

Description

Micro-service decomposition method based on domain-driven design and service panoramic event storm

Technical Field

The invention relates to the technical field of software architecture design and module splitting, in particular to a micro-service decomposition method based on field-driven design and a service panoramic event storm.

Background

Microservice architecture is a method of developing a single application by implementing a set of services organized around business capabilities. The domain-driven design is an object-oriented modeling method for analyzing and designing a large-scale complex software system, changes a method for modeling a database in the traditional software design process, and advocates the domain modeling with a business process as a core. The event storm is a flexible and light-weight workshops organization form, and can help participants build a domain model through close cooperation. For a software system based on a micro-service architecture, if micro-service splitting is not reasonably performed on the software system, on one hand, the subsequent maintenance cost of the software system is increased; on the other hand, the workload of a development team is also increased, and resource waste is caused. Therefore, it is very important to research the microservices splitting method of the software system.

At present, the industry has several independent practices in the aspect of software system micro-service splitting, but none of the micro-service splitting methods has specific implementation steps. In the existing method, research aiming at microservice splitting of a software system is mostly concentrated in a scene with a legacy system, and the legacy system has codes and early-stage operation data which can be subjected to dynamic and static analysis, so that splitting design is simpler. However, more scenes in the industry are to construct a brand-new software system based on a micro-service architecture from business requirements, and such software systems are often not clear in requirements, frequent in change, and free of any running data and codes, and obviously the micro-service splitting method for the legacy system cannot meet the requirements, so that a software design team needs a method for performing micro-service splitting for scenes in which a brand-new software system based on a micro-service architecture is constructed from business requirements.

Disclosure of Invention

The invention aims to provide a micro-service decomposition method based on domain-driven design and a service panoramic event storm, so as to solve the problems in the background technology.

In order to solve the technical problems, the invention provides the following technical scheme: a micro-service decomposition method based on field-driven design and service panoramic event storm comprises the following steps:

step S100, identifying the interest correlators of the target software system at the initial stage of the field drive design, determining the service expectation of the target system with all the interest correlators, analyzing the priority of each service requirement according to the service expectation, enabling the interest correlators to achieve the consensus knowledge on the problem domain of the target software system, and determining the service range and the core service flow of the target software system;

step S200, a workshop phase of a business panoramic event storm, wherein the workshop phase is prepared, a field event and a participant are identified, a key business object is identified, a key event is identified, a boundary context is divided, and context mapping is identified;

and step S300, in the micro-service splitting decision making stage, a final micro-service splitting decision of the software system is made according to a splitting design core principle, external environment factors and non-functional requirements.

Further, the step S100 includes the following steps:

step S101, identifying all stakeholders of the target software system, and reasonably classifying according to the influence and interest degree of the stakeholders on the target software system so as to determine the attention degree of a software design team on the stakeholders;

according to the influence and interest degree of the stakeholders on the target software system, the method is divided into four types in a matrix mode:

the stakeholders with large influence and high interest degree are taken as main attention objects in the implementation process of the method,

the stakeholders with high influence but low interest degree are taken as the satisfactory objects,

the less influential but more interesting stakeholders are taken as the objects of communication,

the stakeholders having a small influence and a low interest level are regarded as objects of interest reduction.

Step S102, making a work plan of a starting stage, determining the available time of each interest correlator, and developing a project starting conference and preliminary requirement investigation of a target software system according to the available time of the interest correlators;

step S103, determining the business expectation of the target system through close communication between a software design team and the stakeholders, enabling all the stakeholders to form consistent knowledge, and refining and summarizing the consistent knowledge;

step S104, judging the priority of each service requirement according to the association degree of the service requirement and the service realization expectation;

step S105, identifying a service pain point of the target software system, namely a problem domain, starting from the service expectation of a stakeholder, enabling the stakeholder to achieve preliminary consensus on the problem domain, and establishing a general language glossary for communication and cooperation;

step S106, determining the service range of the target software system, and further determining the division of duties and the external system and the user role interacted with the target software system;

and S107, determining a core business process according to the business expectation of the target software system and the consensus of the software development team and the stakeholders on the problem domain, and taking the core business process as the main input of the next stage for carrying out the business panoramic event storm workshops.

When the problem domain is analyzed, business expectation and vision need to be always started, and the system is communicated with all interest relatives, so that consistent understanding of the problem domain is formed, in addition, a set of general language suitable for a current target software system is constructed, and a glossary is formed, so that the communication efficiency inside a software research and development team and between the software research and development team and domain experts is effectively improved; the method comprises the following steps of determining a business range of a project so as to clarify the boundary of a whole target software system, wherein the system boundary is an important premise of architecture design, and on one hand, the method can clarify responsibility division and know which contents belong to the field-driven design category; on the other hand, it can be determined in advance which external systems the current system needs to be integrated with.

Further, the problem domain of the target software system includes: a core subfield, a support subfield, a common subfield,

the core subdomain provides a core service value for a target software system, and is a subdomain in which software research and development organizations need to invest most resources subsequently;

the supporting sub-domain is the portion that needs to be custom developed for the target software system in order to achieve the core business value,

the generic sub-domain is a part where existing solutions or service support exists inside or outside the organization,

the universal language glossary is a set of universal languages suitable for the current target software system for communication inside the software research and development team and between the software research and development team and the domain experts.

Further, the step S200 includes the following steps:

step S201, completing preparation work for the business panoramic event storm workshops, comprising: arranging a field, constructing a modeling plane and preparing a modeling tool,

constructing a modeling plane in an arrangement site, drawing a time axis in the modeling plane, marking the direction of the time axis by an arrow, and preparing a modeling tool to model on the modeling plane;

the invention uses a large number of sticky notes of various colors in an event storm workshop for modeling domain concepts such as domain events, event participants, business objects, and bound contexts. The sticky note selected by the business panoramic event storm workshops can be selected according to the requirements of a software design team.

Step S202, according to the core service of the target software system, identifying the field event and the hot spot event,

the field event continuously perfects a universal language glossary constructed in the early stage;

the name of the field event in the invention is expressed by the following modes: the name of the domain event should be named as much as possible without using nouns like "record", "data", "information" because the use of such unrealistic nouns will interfere with the analysis of the subsequent target business object. Generally, the first domain event of most interest is usually posted by the domain expert at the center of the modeling plane, and then events occurring before and after it are written around the event with a head by the participant and arranged from left to right in chronological order. On the modeling plane, parallel processing may be performed using the longitudinal spatial representation. Because there may be some domain events that occur in parallel with other events for the business process of the target software system. At this point, the domain events may be placed above or below the domain events that occur in parallel with them.

Step S203, identifying the participants of each domain event,

in the exploration process of the service panoramic event storm, after the panoramic event stream is obtained, the causes of the events in each field are analyzed and judged, the causes triggering the events in the fields are classified into the following four causes, and the causes are respectively marked by sticky notes with different colors in an event storm workshop:

triggered by the role: marking user roles participating in a domain event;

triggered by the policy: marking a policy that triggers a domain event when a condition is satisfied;

triggered by an external system: marking an external system that triggers a domain event;

triggered by a pre-domain event: that is, the current domain event is triggered by its pre-domain event, which has completed recognition in the previous step, and thus does not need to be marked again;

step S204, identifying a business object most closely related to the domain event,

the business object is a data carrier triggered by a domain event;

in the invention, in a business panoramic event storm workshop, a domain expert can more easily understand the role played by data in a domain model through a business object. The name of the business object will be written on a light gray sticky note and placed over the closely related domain events, indicating the association of the two. It is worth noting that: in this process, there may be a case where a certain domain event is associated with a plurality of business objects, but only one key business object most closely related to the domain event may be identified here.

Step S205, identify key domain events and partition bounding contexts,

the key field event is a field event related to the business, marks the conversion between different stages in different business core flows, and marks the key event by using different marks on a modeling plane;

the marks used by the key field events on the modeling plane can be colored adhesive tapes with different colors;

step S206, identify context mapping and verify bounding contexts,

the context mapping is one of the core concepts in the domain-driven design methodology for discussing the cooperative relationships between bound contexts,

in context mapping, the relationship between two bounding contexts is directional, and the direction of the relationship is opposite to the direction of the dependency, i.e., the depended is upstream, denoted by U in the context map, the dependent is downstream, and denoted by D in the context map.

Participants of the event storm of the invention have divided the solution domain of the target software system into a plurality of modules based on the divide and conquer concept. Although the current results are agreed between domain experts and software development teams, before formally converting a bound context into a microservice boundary, a "check" procedure is also required to verify the rationality of the bound context partitioning from a design point of view. And the identification of the context mapping can help a software development team to mine the cooperation relationship between the bound contexts, so that the rationality of the bound context division is verified, and a foundation is laid for the final microservice splitting.

Further, the identified domain events need to meet the following four basic requirements:

domain events must be facts about the business that occurred in the past;

the domain events must have obvious time point characteristics, and all the domain events are connected to form a reasonable time line;

the domain event must cause a change in the state of a target business object, including: change of state values from none to presence, from presence to absence;

the domain event must be the content of key concern of the service manager and the operator, and if the event is lacked, the domain event can affect the service management and the operation;

when a participant of an event storm has a question or disagreement with a certain domain event or needs to remind business or technical personnel to pay special attention to a certain domain event, the hotspot event can be expressed with a first marker,

when a business event flow branch which is not needed to be considered temporarily occurs or a domain event with disputes or opinions or a domain event needing to be emphasized or corresponding domain logic occurs, the hot event can be marked and represented by using a second mark.

In the present invention, the first indicia may be a pink diamond sticky note and the second indicia may be a pink sticky note.

Further, the partition of the bound context includes two dimensions, which are: a business phase segmentation dimension and a business concept aggregation dimension,

the service stage segmentation dimension analyzes the domain event stream until obvious service stage segmentation occurs or the relationship between two adjacent domain events is very weak, namely the domain event stream can be segmented,

and the service concept aggregation dimension is used for combing all the field events, searching the correlation among the field events according to the participants and the service objects related to the field events, summarizing, refining and aggregating to obtain an integral service concept.

Further, the identifying a context mapping relationship is based on the steps of:

first, two adjacent domain events that span the current bound context are marked,

secondly, whether a direct triggering relation, namely a service calling relation, exists between two field events is analyzed from the aspects of software design and service calling,

and finally, analyzing the limit context of the two field events and judging the upstream and downstream relation.

Further, the core principles of split design also include a single responsibility principle and a highly autonomous principle,

the single responsibility principle refers to the angle that in the micro-service design stage, an architect and a software development team station can generate value for a software development organization on the aspect of service capacity, and review limit context division results obtained through a service panoramic event storm workshop;

the highly autonomous principle is that when the micro-service splitting is carried out, the mapping relation between the bound contexts is considered by combining the technical scenes, and whether a certain dependency relationship exists or not is analyzed, so that the two or more micro-services generate the condition of equidirectional change.

Further, the external environmental factors include: team organization structure, external software system and frequency of business demand changes,

in the team organization structure, because the design structure of the software system reflects the structure of the development organization, each small micro-service is responsible for by a cross-functional team, the number of the cross-functional teams and the team scale which can be formed by the software development team also become the consideration factors for splitting and designing the micro-service, and the experience principle is as follows: a microservice may be fully reconfigured by its cross-job team within a few weeks of time;

the external software system exists in the real environment of a software development organization, and can provide one or more capabilities to influence a plurality of business fields, when the boundary context is designed and divided based on the field drive, the influence brought by the external systems is less considered, and in the final micro-service division stage, the influence brought by the external systems on a target software system needs to be further analyzed, and a micro-service splitting strategy is adjusted in a targeted manner;

frequency of change of business demands, in the context of agile software development, software capability needs to enable business to respond to changes in market demands quickly, and therefore even in the same bound context, domain models with different change frequencies appear.

Further, the business requirements include functional requirements and non-functional requirements,

the functional requirements are based on the service expectation of the target software system, the degree of association between the service requirements and the service expectation is judged and used as the measuring standard of priority,

the non-functional requirements need to be eventually agreed upon through communication with the stakeholders.

Compared with the prior art, the invention has the following beneficial effects: the method can provide a micro-service splitting method of the software system with complete theoretical system and definite implementation steps, provides detailed description for each implementation step of the micro-service splitting method, provides reliable support for micro-service architecture decision of the software system, reduces time and labor cost for developing a micro-service decomposition design process, improves transparency of the design decision process and objectivity of a decision result, and accords with the current and future scenes for designing the software system based on the micro-service architecture.

Drawings

The accompanying drawings, which are included to provide a further understanding of the invention and are incorporated in and constitute a part of this specification, illustrate embodiments of the invention and together with the description serve to explain the principles of the invention and not to limit the invention. In the drawings:

FIG. 1 is a flow chart of a method of microservice decomposition of a domain-driven design and service panoramic event storm based on the present invention;

FIG. 2 is a flowchart of the domain-driven design early stage implementation steps of the microservices decomposition method of the present invention;

FIG. 3 is a problem domain diagram of an exemplary system of an online shopping mall in accordance with one embodiment of the present invention;

FIG. 4 is a system context diagram of an exemplary system of an online shopping mall in accordance with one embodiment of the present invention;

FIG. 5 is a core business flow diagram of an exemplary system of an online shopping mall in accordance with an embodiment of the present invention;

FIG. 6 is a flowchart of the implementation steps of the windstorm phase of the service panoramic event in the micro-service decomposition method according to the first embodiment of the present invention;

FIG. 7 is an exemplary diagram of a domain object modeling sticky note at the business panoramic event storm workshops stage of the micro-servization decomposition method in an embodiment of the present invention;

FIG. 8 is a first domain event diagram of a core business process of an exemplary system of an online shopping mall in accordance with an embodiment of the present invention;

FIG. 9 is a process diagram of deriving domain events from a first domain event back and forth for a core business process of an exemplary system of an online shopping mall in accordance with an embodiment of the present invention;

FIG. 10 is a process diagram of the core business process of the exemplary system of an online shopping mall deriving domain events from the first domain event onwards according to one embodiment of the present invention;

FIG. 11 is a process diagram of the core business process of the exemplary system of the online shopping mall deriving domain events backwards from the first domain event according to an embodiment of the present invention;

FIG. 12 is a domain event flow diagram with hot spots for an exemplary system of an online shopping mall in accordance with an embodiment of the present invention;

FIG. 13 is a domain event flow diagram with participants for an exemplary system of an online shopping mall in accordance with an embodiment of the present invention;

FIG. 14 is a domain event flow diagram with business objects for an exemplary system of an online shopping mall in accordance with an embodiment of the present invention;

FIG. 15 is a portion a of a domain-wide event flow diagram of an exemplary system for an online shopping mall in accordance with an embodiment of the present invention;

FIG. 16 is a portion b of a domain-wide event flow diagram of an exemplary system of an online shopping mall in accordance with an embodiment of the present invention;

FIG. 17 is a portion a of a domain event flow bounding context partitioning diagram of an exemplary system for an online shopping mall in accordance with an embodiment of the present invention;

FIG. 18 is a portion b of a domain event flow bounding context partitioning diagram of an exemplary system for an online shopping mall in accordance with an embodiment of the present invention;

FIG. 19 is a diagram illustrating a bidirectional dependency of a bound context according to a first embodiment of the present invention;

FIG. 20 is a diagram illustrating a bounded context loop dependency according to a first embodiment of the present invention;

FIG. 21 is a diagram illustrating a bounded context bi-directional dependency solution according to a first embodiment of the present invention;

FIG. 22 is a diagram illustrating a bounded context loop dependency solution according to a first embodiment of the present invention;

FIG. 23 is a diagram illustrating a context mapping for an exemplary system of an online shopping mall, in accordance with an embodiment of the present invention;

fig. 24 is a schematic diagram of a decision rule in the micro-server split decision making stage according to an embodiment of the present invention.

Detailed Description

The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.

The term "target software system" as used herein is a software system that a software development organization needs to develop based on business needs.

The term "stakeholder" as used herein is a person within a software development organization that has a stakeholder relationship with the target software system.

The term "microservice architecture" as used herein is a method of developing a single application by implementing a set of services organized around business capabilities.

The term "microservice" as used herein is a single component organized around business capabilities that makes up a microservice architecture-based software system, which in general is made up of several microservices that cooperate with each other.

The term "microservices disaggregation design" as used herein is the process of designing a target software system split into multiple microservices on demand.

The term "common language" as used herein is a core concept in domain-driven design and refers to a unified set of terms for a software development team to collaborate with stakeholders.

The term "core business process" as used herein is the main business process that best embodies the business expectations and vision of the target software system based on business demand research and analysis and communication with stakeholders.

The term "domain expert" as used herein is an expert having a deep understanding of some business domain of a target software system, and a domain expert is a role rather than a specific role.

The term "business object" as used herein is a data object of a domain event when modeling analysis is performed on a target software system, and is therefore a business object because it is considered from a business perspective.

The term "bound context" as used herein is a slice in a domain model that results from identifying different phase divisions of a domain event stream and aggregating for business objects.

The term "context map" as used herein is a representation of the upstream and downstream dependencies between bounding contexts.

For the convenience of understanding, the main inventive concept of the present invention will be briefly described.

By conducting research on the implementation organization of the target software system, identifying all stakeholders of the target software system, making a schedule for starting a meeting and conducting preliminary research on demand according to available time of the stakeholders and the like, then determining the business expectation and vision of the target software system according to the preliminary research process on demand, then determining the priority of the demand proposed by the stakeholders according to the business expectation and vision, then making the stakeholders agree on the problem domain of the target software system, and forming a general language terminology table for communication, then determining the business scope and core business process of the target software system through communication with the stakeholders, then preparing a business panoramic event storm workshop according to the core business process obtained at the previous stage, identifying domain events, identifying domain event participants, identifying key business objects, the method comprises the steps of identifying key field events, dividing limit contexts, identifying context mapping to check the division condition of the limit contexts, producing candidate micro-service decomposition design, and finally making a micro-service decomposition architecture decision of a target software system by combining the candidate micro-service decomposition design, a split design core principle, external environment factors, non-functional requirements and the like, so that the micro-service decomposition design can be accurately carried out in a non-fixed software design team according to the service requirements of the target software system.

Example one

Referring to fig. 1, the technical solution of this embodiment provides a micro-servitization decomposition method based on domain-driven design and service panoramic event storm, which takes a software designer as a main body and provides decision support for the micro-servitization decomposition process of the software designer from the requirement of a target software system. In the discussion of the first embodiment, the micro-service decomposition process of the relatively common "online shopping mall" system will be explained, which specifically includes the following steps:

As shown in fig. 2, the step S100 in this embodiment includes the following steps:

step S101, identifying all interest relatives of the target software system, reasonably classifying according to the influence and interest degree of the interest relatives on the target software system so as to determine the attention degree of a software design team to the interest relatives,

the influence is judged according to the positions of the interest relatives in the corresponding companies of the target software system, different positions correspond to different influence coefficients, the influence coefficient is compared with a first preset value, if the influence coefficient is larger than the first preset value, the influence of the interest relatives is judged to be large, otherwise, the influence of the interest relatives is judged to be small,

the interest degree judges that the interest degree of the interest-concerned person is high if the communication frequency of the interest-concerned person is more than a second preset value according to the communication frequency of the interest-concerned person between the target software system and the software design team, otherwise, judges that the interest degree of the interest-concerned person is low,

the method is divided into four types according to the influence and interest degree of the stakeholders on the target software system in a matrix mode:

the interest-concerned persons with large influence but low interest degree are taken as the satisfied objects,

the interest-related persons with small influence but high interest degree are taken as the objects for keeping communication,

the stakeholders having a small influence and a low interest level are regarded as the objects of reducing the attention.

Illustratively, for the online shopping mall system, the commodity business expert, the payment business expert, the logistics business expert, the after-sales business expert, the customer management business expert, etc. have high influence and high interest, and thus will be used as main stakeholders of the system and main participants of the following event storm stage.

And S102, making a work plan of a start-up stage, determining the available time of each interest-related person, and developing a project start-up conference and preliminary requirement investigation of a target software system according to the available time of the interest-related person.

Specifically, the project initiation session and the preliminary requirement investigation are two main parts of the project initiation phase work plan report. And (4) completing project introduction through a project starting meeting, and researching and knowing the actual requirements of the interest relatives on the target software system through preliminary requirements.

And step S103, determining the business expectation of the target system through close communication between the software design team and the stakeholders, enabling all the stakeholders to form consistent knowledge, and refining and summarizing the consistent knowledge.

For example, for an online shopping mall software system, its business expectations and vision may be summarized as: the user can smoothly complete the processes of commodity choosing, ordering, paying, receiving and the like.

Step S104, according to the association degree of the service requirement and the service realization expectation, judging the priority of each service requirement,

the business requirements include functional requirements and non-functional requirements,

Illustratively, the functional requirement for "user order" is highly relevant to the business landscape of an online shopping mall, and therefore the requirement has a higher priority; the non-functional requirements of both performance and availability require the software design team to trade off with stakeholders, because availability has a greater impact on the user experience for online shopping malls and therefore the availability requirements are prioritized over performance.

And step S105, identifying a service pain point of the target software system, namely a problem domain, starting from the service expectation of the interest-relevant person, enabling the interest-relevant person to achieve preliminary consensus on the problem domain, and establishing a general language glossary for communication and cooperation.

Illustratively, for an online shopping mall software system, the problem domain is shown in FIG. 3. The problem domain mainly comprises a core sub-domain and a support sub-domain, wherein the core sub-domain comprises commodity management, order management, member management and the like; the support sub-domains include payment management, logistics management, customer service, and the like.

And step S106, determining the service range of the target software system, and further determining the division of duties and the external system and the user role interacted with the target software system.

For an online mall system, the scope of its business and the external systems and user roles that interact with it are shown in FIG. 4. The external users mainly comprise users, invoice auditors, return auditors, system managers and the like; the external system mainly comprises a logistics system, a payment system, a tax system and the like.

And S107, determining a core business process according to the business expectation of the target software system and the consensus of the software development team and the stakeholders on the problem domain, and taking the core business process as the main input of the business panoramic event storm workshops at the next stage.

For an online mall system, the core business process is shown in fig. 5, and mainly includes processes of user login/registration, browsing and selecting goods, adding goods into a shopping cart, selecting the quantity of goods, confirming ordering, inventory judgment, filling in receiving information, selecting a payment method, paying an order, judging whether payment is successful, waiting for goods delivery, and applying for invoice.

As shown in fig. 6, the step S200 in this embodiment includes the following steps:

the invention uses a large number of sticky notes of various colors in an event storm workshops for modeling domain concepts such as domain events, event participants, business objects, and bound contexts. The sticky note selected by the business panoramic event storm workshops can be selected according to the requirements of a software design team.

Illustratively, the size and color of the sticky note selected by the business panoramic event storm workshops are shown in fig. 7, and the middle orange-yellow rectangular sticky note is used as the domain event; the hot spots are pink diamond sticky notes; the role uses a yellow small rectangular sticky note; a purple small rectangular sticky note is used as a strategy; the external system uses a pink small rectangular sticky note; the front event uses an orange small rectangular sticky note; the business object uses a gray small rectangular sticky note; the bound context uses a yellow large rectangular sticky note.

the domain events continuously perfect the generic language glossary constructed in the early stage.

For example, for an online mall system, the first domain event identified by the domain expert is shown in fig. 8, and the domain expert may consider "order shipped" as the core domain event that needs to be attended to, and then may post an orange yellow sticky note representing the "order shipped" domain event at an intermediate location on the modeling plane. After determining this core domain event, the participants of the event storm workshop should center on the event, deduce its cause forward, and deduce its result backward. And progressing layer by layer in accordance with such causal relationships between the domain events, one or more domain event streams are developed along the timeline with causal relationships between each other, as shown in fig. 9, where "order shipped" and "? The sticky note is orange yellow.

Specifically, in the process of identifying a domain event, all participants of an event storm workshop should stand as far as possible to think about the domain event from the perspective of business management and operation, and particularly for software developers, the technical thinking needs to be changed into the business thinking. The so-called "causal relationship" between the domain events is also understood here as the analysis of the preconditions for generating the domain events, from which the postresults caused by the domain events are deduced, and from which the postdomain events are deduced.

Illustratively, for the online mall system, a series of domain pre-events as shown in fig. 10, including "order paid" and "order created", can be derived from the domain event "order shipped", and the post-event is orange yellow. By deducing backwards from the domain event of "order delivered", and analyzing the post result, a series of post domain events as shown in fig. 11 can be obtained, including "commodity has signed in", "order has been completed", "return application has been submitted", "invoice application has been submitted", and the like, and the post domain event uses the sticky note of orange yellow.

In particular, if a participant of an event storm has a question or discrepancy with respect to certain domain events, or if it is necessary to alert business personnel or technicians to pay special attention to a domain event, the hot spot may be expressed in a pink diamond sticky note. For example, for an online mall system, an abnormal condition of payment failure needs to be considered for the field event of "order paid"; the field event of 'order delivery' needs to consider different receiving areas and further allocate different delivery warehouses; the field event of 'commodity signed-in' needs to consider that a user can sign in manually or automatically beyond the time limit of receiving goods; the "invoice has been applied" needs to consider that the applicable time limit of the invoice is different for different commodities. These domain events have domain logic that needs to be emphasized, and are therefore marked with a hot event that uses a sticky note pink, as shown in fig. 12.

Step S203, identifying the participants of each domain event,

triggered by the role: marking user roles participating in a domain event;

triggered by a pre-domain event: i.e. the current domain event is triggered by its previous domain event, which has completed recognition in the previous step and therefore does not need to be marked again.

Specifically, the reasons for triggering the domain event include the following four reasons, which are respectively marked with different colors of sticky notes in the event storm workshops:

triggered by the role: marking user roles participating in the field event, and using yellow mini sticky notes for representation;

triggered by the policy: when the mark meets the condition, triggering a strategy of a domain event, and using a purple small sticky note to represent;

triggered by an external system: an external system for marking trigger domain events, represented using a light pink mini sticky note;

Illustratively, for the online mall system, the participants of the domain event are shown in fig. 13, and mainly include users, payment systems, logistics systems, and the like.

Step S204, a business object most closely related to the domain event is identified.

Illustratively, for the online mall system, the key business objects of the domain event are shown in fig. 14, which mainly include orders, payment pipelines, logistics lists, invoice applications, and the like, and the sticky notes used by the key business objects are gray. Fig. 15 and 16 show the final domain event obtained after the key business object is identified, where fig. 15 is a part a of the complete domain event flow diagram of the online shopping mall example system in the first embodiment of the present invention, fig. 16 is a part b of the complete domain event flow diagram of the online shopping mall example system in the first embodiment of the present invention, and the two are combined together, and the part a is on the left side and the part b is on the right side.

Step S205, identify key domain events and partition bounding contexts,

the key domain event is a business related domain event which marks the transition between different stages in different business core flows, and different marks are used on the modeling plane to mark the key event.

The markers used on the modeling plane for key field events in the present invention may be colored tapes of different colors.

Illustratively, for the domain event flow of the online mall system, a plurality of key domain events, namely "goods have been added to a shopping cart", "inventory has been locked", "inventory has been deducted", "inventory has been released", "goods have been removed from a shopping cart", and "order has been completed", etc., are segmented by the business phase, and thus a plurality of bound contexts are divided, mainly including "shopping cart context", "order context", "payment context", "logistics context", "return context", and "invoice context". And through business concept aggregation, the events related to the commodity are found to have certain independence, and in the early starting stage, the commodity management is also considered as a core sub-domain in the problem domain of the target software system. Thus, in summary analysis, in addition to the bound context previously identified longitudinally, a "commodity context" should also be added. A large yellow sticky note may be used for the identified bounding context, as shown in fig. 17 and 18, where fig. 17 is a part a of the domain event flow bounding context partition diagram of the online shopping mall example system in the first embodiment of the present invention, and fig. 18 is a part b of the domain event flow bounding context partition diagram of the online shopping mall example system in the first embodiment of the present invention, where the two are combined together, and the part a is on the left and the part b is on the right.

Step S206, identify context mapping and verify bounding contexts,

in context mapping, the relationship between two bounding contexts is directional, and the direction of the relationship is opposite to the direction of the dependency, i.e. the depended is upstream, denoted by U in context mapping, the depended is downstream, denoted by D in context mapping;

specifically, the identification of the context mapping relationship is based on the following steps:

Specifically, after the context map of the target software system is obtained, it needs to be analyzed whether a case that two contexts are upstream and downstream of each other as shown in fig. 19 or a case that three or more bound contexts are cyclically dependent as shown in fig. 20 occurs. When two bound contexts are upstream and downstream of each other, if the microservices are designed based on the current partition, the coupling degree between the two microservices is possibly too high, and a situation that the two microservices are changed in the same direction is caused (namely, in the two microservices, the change of any microservice necessarily causes the change of the other microservice), so that the characteristic that the microservices are independently issued is influenced. For cyclic dependencies, the effect is similar to the former. Therefore, such a situation should be avoided as much as possible when performing microservices splitting.

For the above problem situation, there are two solutions:

mining unrecognized domain concepts: analyzing whether unidentified domain concepts such as domain events, business objects and the like exist in the boundary context with problem relationships, and further mining the domain concepts and seeking help of domain experts if necessary. The desired result of such coping strategies is to split up one or even more new bounding contexts, which it is desirable to be able to form context mappings as shown in fig. 21 and 22.

Merging mutually upstream and downstream bound contexts: for two bound contexts which are upstream and downstream of each other, if no unidentified domain concept is found, merging can be considered under the condition of conforming to the 'single responsibility principle', the opinion of a domain expert needs to be fully heard during merging, and preparation is made for the merged bound context to be split again along with the continuous evolution of services and architectures.

Illustratively, for the domain event stream of the online mall system, a context mapping relationship as shown in fig. 23 is obtained.

Step S207, the candidate micro-service decomposition design is produced.

Specifically, the bound context and the context mapping completed by the analysis are converted into the candidate microservices decomposition design.

Illustratively, according to the analysis result, the online mall system can be decomposed into 7 candidate micro services such as return goods, logistics, invoice, payment, order, shopping cart and goods.

Step S300 in this embodiment is to make a final software system microservice splitting decision according to the splitting design core principle, external environment factors, and non-functional requirements, as shown in fig. 24.

In particular, the split design core principles include single-responsibility principles and highly autonomic principles.

Illustratively, the business responsibility of 7 candidate micro-services such as goods return, logistics, invoice, payment, order, shopping cart and goods is obviously single, so that the principle of single responsibility is met. And analyzing according to the context mapping relation, and the condition of bidirectional dependence or cyclic dependence does not exist, so that the candidate micro-service splitting design also accords with a highly autonomous principle.

External environmental factors include team organization, external software systems, and frequency of business demand changes.

Illustratively, through the above-mentioned factors, considering the organization structure of the team for the online shopping mall system, for the return, logistics, invoice, payment, order, shopping cart, commodity and other 7 candidate micro-services, if there are only 6 teams, the micro-service with a relatively close combination relationship, such as order and payment, can be considered, so that the system is divided into 6 micro-services corresponding to 6 teams, i.e. return, logistics, invoice, order and payment, shopping cart, commodity. Considering the external software system, the logistics and invoice management is taken charge of by the external system, so the external system is excluded as the micro-service, and the micro-service of the software system is decomposed into 4 micro-services of goods returning, order and payment, shopping cart and commodity. Considering the frequency of change of business demand, as the frequency of change of order payment business is different between members and non-members, the non-member order payment business is stable, and the member order payment business changes more, therefore, the order and payment are divided into two micro services of member order and payment management, non-member order and payment management, and then 5 micro services such as goods return, shopping cart, commodity, member order and payment, non-member order and payment and the like are obtained.

For example, for non-functional requirements, in the micro-services currently divided in the online shopping mall, the commodity micro-service and the shopping cart micro-service are accessed frequently, so that high performance is required, and the order and payment are required to ensure safety and availability, so that the current micro-service decomposition design is reasonable. Therefore, the online shopping mall system is ultimately divided into a commodity microservice, a shopping cart microservice, a return microservice, a non-member order and payment management microservice, and a member order and payment management microservice.

It is noted that, herein, relational terms such as first and second, and the like may be used solely to distinguish one entity or action from another entity or action without necessarily requiring or implying any actual such relationship or order between such entities or actions. Also, the terms "comprises," "comprising," or any other variation thereof, are intended to cover a non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements does not include only those elements but may include other elements not expressly listed or inherent to such process, method, article, or apparatus.

Finally, it should be noted that: although the present invention has been described in detail with reference to the foregoing embodiments, it will be apparent to those skilled in the art that changes may be made in the embodiments and/or equivalents thereof without departing from the spirit and scope of the invention. Any modification, equivalent replacement, or improvement made within the spirit and principle of the present invention should be included in the protection scope of the present invention.

Claims

1. A micro-service decomposition method based on field-driven design and service panoramic event storm is characterized by comprising the following steps:

step S300, in a micro-service splitting decision making stage, a final micro-service splitting decision of the software system is made according to a splitting design core principle, external environment factors and non-functional requirements;

the step S200 includes the following steps:

step S201, completing preparation work for a business panoramic event storm workshop, comprising the following steps: arranging a field, constructing a modeling plane and preparing a modeling tool,

step S203, identifying the participants of each domain event,

the business object is a data carrier triggered by a domain event;

step S205, identify key domain events and partition bounding contexts,

step S206, identifying the context mapping relationship and verifying the bound context,

step S207, outputting a candidate micro-service decomposition design;

the identified domain events need to meet the following four basic requirements:

domain events must be facts about the business that occurred in the past;

domain events must cause the state of a target business object to change, including: change of state values from none to presence, from presence to absence;

when business event flow branches which are not needed to be considered temporarily occur, or domain events with disputes or opinions or domain events needing to be emphasized or corresponding domain logics occur, the business event flow branches can be marked as hot events and are represented by using a second mark;

the partition of the bound context includes two dimensions, respectively: a business phase segmentation dimension and a business concept aggregation dimension,

2. The method of claim 1, wherein the method comprises the following steps: the step S100 includes the following steps:

step S101, identifying all interest correlators of the target software system, and reasonably classifying according to the influence and interest degree of the interest correlators on the target software system so as to determine the attention degree of a software design team on the interest correlators;

3. The method of claim 2, wherein the method comprises the following steps: the problem domain of the target software system comprises: a core sub-domain, a support sub-domain, a generic sub-domain,

4. The method of claim 1, wherein the method comprises the following steps: the identifying a context mapping relationship is based on the steps of:

5. The method of claim 4, wherein the method comprises the following steps: the split design core principles also include single responsibility principles and highly autonomic principles,

6. The method of claim 4, wherein the method comprises the following steps: the external environmental factors include: team organization, external software systems, and frequency of business demand changes.

7. The method of claim 2, wherein the method comprises the following steps: the business requirements include functional requirements and non-functional requirements,