Finding Microservice Boundaries

Challenges in Microservice Decomposition

• Determining where to separate services is a fundamental challenge in microservice architecture.
• Incorrectly defined boundaries can create a distributed monolith, requiring coordinated releases and reducing flexibility.
• Proper separation leads to adaptable architectures that meet customer needs efficiently.

Key Tools: Domain-Driven Design and Event Storming

• Domain-Driven Design (DDD) is essential for defining service boundaries; also referred to as the “Big Blue Book.”
• DDD focuses on the core domain, encourages collaborative model exploration, and promotes the use of a ubiquitous language within explicitly bounded contexts.
• Ubiquitous language: everyone (technical and non-technical) uses the same terms throughout the system, avoiding confusion.
• Bounded context: defines clear linguistic and organizational boundaries, analogous to microservices.
• Event storming is highlighted as a collaborative technique that brings different stakeholders together to map out user flows and system events using sticky notes.

Steps to Effective Event Storming

• Gather a diverse group (technical and non-technical) for the event storming workshop.
• Map all possible system events (e.g., order created, order delivered) with sticky notes.
• Arrange events in chronological order according to the user journey.
• Identify the actor or trigger for each event, the command or action taken, and the relevant subsystem.
• Group related events and actions to identify preliminary bounded contexts, which can correspond to specific microservices (e.g., ordering service, barista service).

Best Practices and Critical Advice

• Establishing boundaries is crucial before starting implementation—don’t write a line of code before sorting this out.
• Use language that best suits the business, particularly when there are conflicting terms in the workshop.
• Ensure equal participation from business and technical stakeholders, keeping discussions focused on business needs rather than technical details.
• Early engagement in these processes helps teams in the long run to avoid implementation pitfalls.

Suggested Action Items

• Organize event storming workshops including both technical and non-technical stakeholders to define microservice boundaries.
• Enforce usage of a ubiquitous language aligned with business terminology in documentation and code.
• Facilitate buy-in from development teams by highlighting the long-term value of proper boundary definition.