Domain Discovery
Introduction
In this section, the team will validate the event storming results versus the old domain model. Based on the results, we will then create domain models for the discovered entities and attributes.
Preconditions
- Event Storming workshop to identify the needed domain events, commands, and services.
- PlantUML tool or any tool that allows you to model domain easily.
Steps
1. Validate results against existing domain model application
Since the current CRM management doesn’t fit all of our requirements now, it is obvious that we do not want just to transfer the old domain model into a new application. Instead, the goal of the validation against the old model is to prove whether the still known requirements / data were considered.
To validate the suitability of the newly undertaken domain discovery, Jack and Alexander worked on comparing the new results first with the domain model of the existing CRM system. Especially, we wanted to discover whether we missed some requirements covered by the old system. To get a better understanding of the existing, Alexander sketched this existing CRM domain model as UML model.
We have used PlantUML software to sketch the UML model.
2. Validation Outcome
After several iterations of discussions between the team, Jack and Alexander listed down all the solid points
- Outcome of Event storming is valid.
- Old domain model does not fit future requirements.
- Not flexible enough, e.g. address data directly in the domain object Account or Contact.
- Only one Responsible for Account or Contact.
- Status for Accounts and Minutes are not considered.
- Minutes can only be associated to e.g. one Account.
- Not completely up-to date where some information is missing such as the call was a video call.
- It is not taken into consideration that a Customer / Account and Contact is a specific role of a Party.
- Not aligned to standards (ISO 20022 for Party).
3. Create a domain model for the entities and attributes discovered using PlantUML
Based on the Event Storming results and the attributes from the old application, our business analysts created UML sketches for the relevant domains. Meanwhile no more needed information were left out.
It is not the purpose of the Event Storming workshops to identify all of the properties etc. the aggregates needs!
As a result of the Event Storming, we have identified the following aggregates:
-
Customer
-
Minutes
-
Contact
Customer Aggregate

Customer Domain and in the Customer aggregate contained entitities could be derived from Event Storming results. Many of the information needed for a Customer (e.g. addresses) is already managed in the Party Domain and must not be redundant for the Customer. Customer Domain also needs to integrate two other domains: Employee and Party (for Customer and Contact).
Minute Aggregate

Domain model for Protocol is very similar to the existing in the legacy system. But, the event storming brought up some necessary adjustments. A Protocol shall be associatable to not only one “Reference Point” (e.g. a Customer), but to many. Also status Entity should be introduced instead of draftFlag. We have found the need to have additional attributes for the CallNotes to set the type of the call. Domain integrates Employee and Party Service (both needed for MeetingParticipants). Additionally, commands correspond to these in the Event Storming discovered.
Contact Aggregate
Contact aggregate was discovered when we digged deep down into the customer domain. Event storming showed the importance of having a separate contact aggregate and relate the customer to one or more contacts.
4. Discovered External systems
Also as a result of the event storming, we have identified two main external systems which are the Party and the Employee. The party management external system is directly connected to the customer creation, contact creation. While the Employee management external system is related in the participants of the meetings in our CRM system.