Identifying Domain Boundaries
Introduction
Based on the outcome of the event storming session (the identified aggregates and bounded contexts), the team had to now define the relationships of the bounded context and need to identify the single services to move forward in this process.
Steps
Results of Event Storming Session
As result of the event storming session, we have identified different bounded contexts and aggregates below:
The identified bounded contexts were found:
-
Party Management (existing external system)
-
Employee Management (existing external system)
-
Customer Management
-
Minutes Management
Regarding the bounded contexts "Party" and "Employee" which were identified from external systems, Adam suggested that the team should not work further on it except defining the relationship to the other bounded contexts that has been identified as "Customer" and "Minutes".
The identified aggregates were found:
-
Party (external system)
-
Employee (external system)
-
Customer
-
Contact
-
Minutes
Bounded Context Relationship
As the next step, the team incooperated various bounded context and their relationships into a context map. To do this, we all discussed the possible relationships between the identified bounded contexts.
As the Party and the Employee Management bounded contexts were considered as being generic and used for different purposes, Jack concluded that their relation to Customer and Minutes Management must be of the type "Open Host Service / Published Language", since the Party and Employee services are already providing information and are comprehensively documented. These services are also providing versioning in their API. Additionaly, the upstream bounded contexts supports multiple consumers and are not considered to support specific requirements of one consumer.
The relationship between Customer and Minutes was being considered as partnership as both teams working on these 2 bounded contexts are going to work on aligned and dependent goals. In additional, each team understand at least some of the partners ubiquitious language.
The summarized result of this discussion was this context map:
Service Boundary Discussion
Based on the discussion already in the event storming, we have identified bounded contexts "Customer" and "Minutes" with their aggregates "Customer", "Contact" and "Minutes". After the bounded context, we also applied the following coupling criteria to assess the service boundaries. Into the consideration team took the following bounded context:
- Customer Management
- Minutes Management
We have applied the service cutter rules discussed in the following article Service Cutter Rules
Taking especially the first four criteria into our consideration the team came to the conclusion that especially the strong dependencies between Customer and Contact and their semantic proximity and the shared owner speaks for having a Customer Management and a separate Minutes Management service.
In addition, Adam hinted that assessed Customer and Contact to have the same Availability Criticality, Network Traffic Similarity and Security Criticality, that encourages the conclusion.