Appreciate having your support on building this workshop, hope this workshop is useful & meaningful for you. In order to well organize all of the contents for DDD practitioners reference, the workshop will be refactored to cover wider topics with a more complex business scenario sample. Plan to release new content before the end of 2021, stay tuned.
In this ddd-practitioners-reference, you will learn more than classic Domain-Driven Design Strategic design and Tactical design patterns. DDD is good to approach decision makers to align business goals among diversity stakeholders in different BU.
When learning a series of methodology would always bored ourself and lot passion on the unlimited learning journey, so i'll walk you through a bsuiness case to practice the following methodologies/approaches to get familiar in using DDD to design solutions.
So, this guide will cover below topics whaich are what I learned from WW communities (ddd_eu, virtualddd) and awesome ddd-practitioners experience.
Outline:
- A sample business story - Trip Service
- Awaren businesss context by Wardley Maps
- Kowing your key stakeholders - Impcat Mapping
- EventStorming
- Bounded Context Canvas - founded by Nick Tune
- Aggregate Design Canvas (*) - founded by Kacper Gunia
- Aggregate Canvas (*) - founded by Arthur Chang
- Example Mapping
- Specification by Example
- Implement DDD Tactical pattern in Clean Architecture with Spring boot framework - refer to awesome-trip
- Integrate with AWS cloud native offerings
- 00 - Event Storming
- 01 - Hands-on: Events exploring
- 02 - Cafe business scenario
- 03 - Roles, Commands, and Events Mapping
- 04 - Modeling and Development
- 05 - Deploy Applications by AWS CDK
Event Storming is a rapid, lightweight, and often under-appreciated group modeling technique that is intense, fun, and useful to accelerate project teams. It is typically offered as an interactive workshop and it is a synthesis of facilitated group learning practices from Gamestorming, leveraging on the principles of Domain Driven Design (DDD).
You can apply it practically on any technical or business domain, especially those that are large, complex, or both.
Event Storming isn't limited to just for the software development team. In fact, it is recommend to invite all the stakeholders, such as developers, domain experts, business decision makers etc to join the Event Storming workshop to collect viewpoints from each participants.
Reference from Kenny Bass - https://storage.googleapis.com/xebia-blog/1/2018/10/From-EventStorming-to-CoDDDing-New-frame-3.jpg
Take a look on this diagram, there are a few colored sticky notes with different intention:
- Domain Events (Orange sticky note) - Describes what happened. Represent facts that happened in a specific business context, written in past tense
- Actions aka Command (Blue sticky note) - Describes an action that caused the domain event. It is a request or intention, raised by a role or time or external system
- Information (Green sticky note) - Describes the supporting information required to help make a decision to raise a command
- Consistent Business Rules aka Aggregate (Yellow sticky note)
- Groups of Events or Actions that represent a specific business capability
- Has the responsibility to accept or fulfill the intention of command
- Should be in small scope
- And communicated by eventual consistency
- Eventual Consistent Business rules aka Policy (Lilac sticky note)
- Represents a process or business rules. Can come from external regulation and restrictions e.g. account login success/fail process logic.
Business requirements can be very complex. It is often hard to find a fluent way to help the Product Owner and Development teams to collaborate effectively. Event storming is designed to be efficient and fun. By bringing key stakeholder into the same room, the process becomes:
-
Efficient: Everyone coming together in the same room can make decisions and sort out differences quickly. To create a comprehensive business domain model, what used to take many weeks of email, phone call or meeting exchanges can be reduced to a single workshop.
-
Simple: Event Storming encourages the use of "Ubiquitous language" that both the technical and non-technical stakeholders can understand.
-
Fun: Domain modeling is fun! Stakeholders get hands-on experience to domain modeling which everyone can participate and interact with each other. It also provides more opportunities to exchange ideas and improve mindsharing, from various perspective across multiple roles.
-
Effective: Stakeholders are encouraged not to think about the data model, but about the business domain. This puts customers first and working backwards from there, achieves an outcome that is more relevant.
-
Insightful: Event Storming generate conversations. This helps stakeholders to understand the entire business process better and help to have a more holistic view from various perspective.
There are many useful applications of Event Storming. The most obvious time to use event storming is at a project's inception, so the team can start with a common understanding of the domain model. Some other reasons include:
- Discovering complexity early on, finding missing concepts, understanding the business process;
- Modelling or solving a specific problem in detail;
- Learning how to model and think about modelling.
Event Storming can also help to identify key views for your user interface, which can jump start Site Mapping or Wireframing.
Let's get started with a quick example to demonstrate how to run a simple Event Storming.