当前位置:网站首页>Joking Domain Driven Design (VI) -- Boundary context -- Design

Joking Domain Driven Design (VI) -- Boundary context -- Design

2022-06-21 08:14:00 SKevin

   Bound context ( abbreviation BC) It's a hard part to tell . I wonder if I can find more articles , See what others say , But after hesitation, I decided to talk according to my own understanding , All kinds of materials are plagiarized . As for whether what you said is correct , You must also make good judgment , After all, everyone has his own understanding . As a part of reviewing the old and learning the new , Here is the summary of BC Repeat the characteristics of , It's not to make up words ,DDD It takes a lot of wordiness to remember , After all, there are so many concepts . Besides , To enhance your reading experience , The clearance context is divided into two sections to explain .

  BC Its characteristics include four aspects :1) Is the physical division of the system ;2) The derivation should be based on the definition of the subdomain ;3) It defines the boundary of the domain model , It is a division and limitation of domain model ;4)BC Each domain term in the has and only has a clear meaning ( Common language ).

  BC The design of is usually derived from subdomains . If will DDD The guidance of is divided into three parts : Subdomain design 、BC Design and code design ,BC Belongs to the second floor , Play a connecting role , Provide macro guidance in transforming business models into technologies .BC The process of definition is to confirm that there are several subsystems ( or Java In the package 、.NET Namespace in ), What are they? Domain model ( The domain model here is a business term and does not mean ‘ class ’ or ‘ Interface ’) And how subsystems interact . It can be seen from the above concept , Discuss BC There are both business and technical contents .

Domain model

1、 The use of domain models runs through “ analysis ”、“ Design ”、“ Development ” The whole process of , All kinds of people should use domain model for communication , Avoid aliasing of system requirements during implementation

2、 The domain model only reflects that the business has nothing to do with technology , It includes not only entities in the business such as “ Order ”、“ Customer ” And other business processes, such as “ Place the order ”

3、 Domain models have boundaries , We should only focus on what the business is concerned about

   When entering BC Before the discussion , First of all, I will introduce some basic concepts to avoid the mask on your face when we use them later , It's my fault that I didn't talk about it in advance . The first word introduced is “ modeling ”, The second word to be introduced is “ Model ”. Whether as a software developer or a novice , You may have heard this word countless times on countless occasions . At present, I am a newcomer , Anyone who listens to say that they are doing software modeling , The first impression I got was that this man was a proper Daniel . What exactly does it mean ? Let's put it another way : For example, there is such a thing , I am stupid to tell you , Then write a paragraph or draw a picture . Anyway, no matter what means , As long as you understand my intention, we will achieve this goal . What I'm talking about here “ A piece of writing ” or “ chart ” It's the model , The process of doing this is called “ modeling ”. So whether you are designing a subdomain or BC Or draw a flow chart , It's all modeling , I don't know why I have to use it “ modeling ”,IT The circle just doesn't like talking about people .

   Digression : China IT I think the translation of some words is unprecedented : Handle 、 polymorphic 、 modeling 、 Closure …… This translation , To fight against .

   Back to the point , In software design activities ( Strictly speaking, it is in UML In the process of modeling ) It contains three types of models : business model 、 Analysis model and design model , The specific explanations are listed below . But let's say one more thing , Our common class diagrams 、 Sequence diagram , Don't think that these models are only used in the design phase before implementation , It can also be used in the business analysis stage , Just for different purposes . Don't go back and say that class diagrams are only used in the software design phase , Just tell the layman , Professional we need to have professional quality .

  • business model : Various documents or diagrams used to explain and explain business logic , It has nothing to do with whether there is a computer , It is a description of the objective business . Subdomain design is business model design .
  • The analysis model : It is used to describe which businesses can be implemented in the software system ( Not all businesses can be implemented in software , This is why we often see development and product managers tearing each other apart ), The business model is connected above it, and the design model is corresponding below it .BC Design is the design of analytical model .
  • The design model : It is used to describe the design method of software at the code level , Common examples are class diagrams 、 Activity diagrams 、 Sequence diagram, etc .DDD The models built in the tactical phase are like aggregation 、 The entity is the design model .

   I not only said three models, but also set them in DDD On , First, there is no digression , Second, it is professional . Can this thing come back , I admire myself . Another important point , In all the models , Documentation is the most important , You can experience it by yourself . About documentation , And a few more words . Generally speaking, it is not recommended to spend energy on writing a large number of documents in the code design phase , First, it will take a lot of time. Second, few companies can guarantee that the code changes and the documents change at the same time , In this case, the document not only fails to explain the problem, but also delays things .But, Business model documentation is required , The rate of change is not very high . Don't carry it with me , The business model of an enterprise changes every day , I advise you to leave as soon as possible , He couldn't find his way . As for the analytical model , It is a transitional document , As the case may be .

   The previous chapter shows the domain map of personal wechat , In order to avoid misunderstanding, this section uses a paragraph “ Even if the communication software ” The back-end architecture of is taken as an example to show the design diagram of the clearance context , Since there is no actual software , You can still use wechat as a comparison . I have to avoid suspicion first , When Tencent looked for it, it was shrimp …… in addition , The actual system architecture is much more complex than the case , The division will be more detailed . This is just an introduction to how to proceed BC Design , You need to learn to draw inferences from one instance in your daily work , This is also the correct posture for learning . Time is long. , You can understand what it is “ looking for him for thousand times in the crowd , Suddenly look back , That person but in , The lights are dim ”.

 

    In order to explain the problem , In this example, the “ Applet management subdomain ” and “ Authentication subdomain ” Removed , A picture is not easy to draw ( In fact, it mainly affects your reading experience ). Besides , The previous chapter dealt with “ Address book subfield ” and “ Chat subdomain ” The design of is not detailed enough , It needs to be refined . The following figure shows the refinement results of two subdomains , Be careful : The design here is still a subdomain graph , Not yet BC design phase .

 

      

    After the subdomain is refined, we establish the following BC chart , It should be noted that BC Each gauge context should be represented by a solid line in the design drawing , because BC Having physical properties is no longer a conceptual model , BC The interaction between them is connected by solid lines .

 

 

    BC The design of not only needs the sub domain design as a reference , It also needs to be calculated according to the actual situation of your team and the company . The construction of this case is carried out by the same department 200 A team of members , Including research and development 、 test 、 Operation and maintenance 、 The product manager 、 Basic roles such as project manager , Due to abundant resources and complete posts , Determine to use the microservice architecture as the solution for system implementation . Let's explain the design basis of this scheme in detail .

  1. Chat subdomain : It is divided into “ Communication management ” and “ Historical message management ” Two subsystems , The former is used in chat scenarios, such as sending various texts 、 Pictures, etc ; The latter is used to store historical messages for recording queries . these two items. BC The business points of concern are very different , The boundary is obvious , Two BC It can use different system architectures and evolve independently .
  2. Message audit uses a real-time audit system purchased by a third party to audit the circle of friends or messages sent by users to avoid the existence of illegal content .
  3. The address book subfield is divided into two BC:“ contact manager ” and “ Friend relationship management ” It is used to manage the contacts of this account and the recommendation system for friends' recommendation .

    Generally speaking BC And subdomains can correspond to each other one by one . Of course , It also depends on the structure of your company and team . Let's say that the design of subdomains is the beginning of the project , that BC The quality of the design can almost determine the success or failure of the system , It should be the place where the most energy is invested in the design process . The reason has already been mentioned before : Subdomains delineate small physical systems , Natural isolation effect , When your system has good BC When the design , Even if one BC Failure will not lead to the business avalanche of the whole system . Later we will talk about DDD You will find out why BC Isolation is the most central and critical .

  BC Design granularity , At a large scale, it can actually be a subsystem itself , There is only one single system BC( In this case , A single system is no longer pure BC, Should take “ package ” or “ The name space ” As BC The basic unit of ); On a smaller scale , The minimum particle size is “ polymerization ”, Bear in mind ! It really can't be any smaller . No matter how big or small , The key design principles are “ complete ” namely BC It can support a business completely , In other words, every BC Should be autonomous and separate from others BC There are clear boundaries . actually , When you are in BC When designing, you will find that in most cases, you are looking for BC Boundary is a very natural process , Or that sentence : People are spiritual .

Be careful !

System construction process ( The development phase ) in , Make sure that your domain model does not leak out to BC outside , there BC It can be a project, a package or a namespace .BC The interaction between them can only be through DTO Or news ( In fact, news is also a kind of DTO)

     actually ,BC There are still many principles to follow in the design process of , List them one by one .

  1. BC The design of is the macro architecture design of the system , Once confirmed, it needs to be implemented on this basis
  2. Based on the business dimension BC Design . There will be exceptions to this rule : Front end and back end separation architecture , It is a kind of typical technology - based BC design methods . Whether the front end belongs to BC Some of the issues are still controversial , The answer in more authoritative books is also “Yes”, Therefore, the micro front-end technology is also introduced . Personally, I suggest that it depends on your company and team , Don't stick to theory .
  3. BC The design needs to include the technical level of the team in your organizational structure 、 Team structure 、 Whether it crosses departments 、 Human resources, etc. as a reference, so as to avoid that the design scheme can not be implemented even though there is a design scheme , Fall into the realm of armchair talk , Waste of preliminary work .
  4. BC It also needs to keep changing , Especially when the subdomain is changed
  5. DDD The most important rule in is “ Exercise and adaptation ”, Everything is changing , You need to adjust to changes at any time
  6. In reality , Some leaders like to design according to the development task BC, In this case, it is better to use less to reduce the situation of throwing the pot . in addition , Personal advice BC Only one person is responsible for the development of the project service To the bottom dao, Don't involve too many people in the same aggregation , Everyone has their own design ideas , It is very easy to have repetitive content ; It is also easy to interrupt the coherent thinking of a R & D personnel . If BC more , Please also limit to one team to reduce communication costs
  7. In fact, there is no standard for the identification of bounded context , It can be achieved through business complexity 、 Manage complexity and technical complexity to analyze and identify , Iterative analysis .

   To make you understand , Let's take another example . Take an e-commerce shopping system as an example , Show it BC Design method of . In this case , Fewer team members , The developer is responsible for the operation and maintenance ; The system customer objects are mainly internal users . For convenience , We will still show only a few subdomains : Sales sub domain in the core domain , As shown in the figure below .

   According to the subdomain description shown in the above figure , It is deduced as follows BC Design .

   Different from the first case , This example does not use the microservice architecture , Instead, it uses a single architecture as its landing method . I know that some people are strong proponents of microservice Architecture , But I still need to emphasize here : When selecting the architecture of the system , Technical competence is only one aspect , And it's only a small aspect . There are many factors that determine our architectural choices , For example, the comprehensive ability of the team ( Be careful : We can't decide whether there are oneortwo experts in the team to determine the comprehensive ability of the team )、 Team structure 、 The overall structure of the company ( Especially when the system you want to do is the business middle office ) etc. . It has been stated in the project background “ Develop part-time operation and maintenance ”, Explain that the current team uses container deployment 、 Link tracking 、 Full stack monitoring and other technologies will be reluctantly , Even if forced into the system, the results you want will not match your expectations due to insufficient resources .

   Finally, I need to say , We all know that microservice architecture has various advantages , We also know that the monomer system has various shortcomings . But every business has two sides , When you use it, you need to comprehensively evaluate your own conditions . Besides , Your system is not a one-off deal , With the investment of follow-up resources , You can optimize the architecture .

原网站

版权声明
本文为[SKevin]所创,转载请带上原文链接,感谢
https://yzsam.com/2022/02/202202221502060936.html