In the world of software development, having a solid understanding of domain boundaries is essential for building resilient applications. However, the process of defining these boundaries frequently presents itself as a complex and challenging task. Considering the fact that domain knowledge is distributed among various domain experts, it becomes essential to adopt an approach that facilitates the consolidation of this knowledge. This is where Event Storming comes into play — a powerful technique that helps teams navigate the complexities of requirements and effectively identify distinct domain boundaries. In this article, we will explore how Event Storming can be leveraged to uncover potential domain boundaries.

Let’s explain various indicators that can help in identifying potential candidate domain boundaries:

· Expertise Segmentation: One significant sign of a potential domain boundary is the presence of distinct groups of domain experts who possess specialized knowledge and expertise in specific areas. When different domain experts have different perspectives and focus areas within a larger system, it suggests the possibility of defining separate domains.

· Pivotal Events: Identifying pivotal events within a domain can be instrumental in recognizing potential domain boundaries. Pivotal events are significant occurrences or milestones that have a significant impact on the system. These events often act as triggers for various processes, actions, or decisions, and they can help demarcate different domains based on their specific responsibilities and interactions.

o Example: Let’s take the context of recruitment as an example. Within this domain, we can identify three key events: “JobSeekerApplied”, “JobSeekerAccepted” and “OnBoardingProcessStarted”.

In the recruitment process, a job seeker initiates their application by submitting the necessary information and documents, which triggers the “JobSeekerApplied” event. Once the application is reviewed and assessed by the hiring team, they make a decision on whether to accept or reject the applicant. When the decision is positive, the “JobSeekerAccepted” event occurs, indicating that the job seeker has been accepted for the position.

Following the acceptance of the job seeker, the next significant event is the “OnBoardingProcessStarted”. This event represents the commencement of the onboarding process, which involves integrating the new employee into the organization and providing them with the necessary resources and information to begin their role. Therefore, in this particular example, the occurrence of the “JobSeekerAccepted” event triggers the subsequent event of “OnBoardingProcessStarted” indicating that the onboarding process will be initiated after the job seeker has been accepted for the position. Therefore, the event “JobSeekerAccepted” holds significant importance in this scenario and serves as a pivotal event.

*To identify pivotal events, consider the following questions:
*
· Are there any events that cannot occur without the prior occurrence of another event?

· Are there any processes that depend on the occurrence of specific events?

· Collaboration Trigger: During an event storming workshop, it is not uncommon to observe a situation where a domain expert is waiting for another person to introduce an event onto the shared board before actively participating in the collaborative session. This behavior can indicate that these individuals have different domain boundaries, and the first person is specifically waiting for a pivotal event to occur. Once this pivotal event takes place, they can then engage and collaborate effectively. By observing such behavior, it becomes apparent that distinct domain boundaries exist.

· Semantic Variations: In complex domains, it is common for a single term or word to possess multiple interpretations or meanings depending on the context. This phenomenon arises when stakeholders or domain experts use the same word but attribute different significances to it. Such variations in meaning often indicate the presence of distinct domain boundaries, emphasizing the need to establish a shared understanding. When different individuals within a domain use the same term but assign divergent meanings, it can lead to misunderstandings, miscommunications, and inefficiencies. It highlights the existence of separate perspectives and knowledge domains within the larger system.

o Example: In the context of tourism, a “tourism ticket” typically refers to a document or voucher that grants access or admission to a specific tourist attraction, event, or activity. On the other hand, in the context of issue tracker systems, a “ticket” refers to a record or item that represents a specific task, problem, or request within the system. It serves as a standardized unit of work that aids in tracking and managing issues, bugs, feature requests, or other types of tasks that require attention. This example highlights the use of the word “ticket” in two distinct contexts, indicating a clear indication of different subdomains.

Conclusion:

Event Storming is a game-changer when it comes to discovering domain boundaries and shaping the architecture of software systems. By embracing this collaborative and visual technique, teams can navigate the chaos, gain clarity, and establish robust domain models. With Event Storming, you can empower your team to build better software that truly aligns with the needs of the business and its stakeholders.

Remember, the journey from chaos to clarity begins with Event Storming. Embrace this powerful technique and unlock the potential of your domains.