The core of visual meetings like EventStorming is that we discuss only explicit and visible things. Mark these with a bright pink sticky called a hotspot, something that is noticeable from a distance. At this point, expect to find different opinions about the expertise. Often people assume a Domain Event is the same even but isn’t. Remove duplicate events, but make sure they are in fact duplicates. Let the attendees enforce the timeline now by making the story consistent. When everyone wrote down their domain events, it is time to tell a story. There will be a lot of chaos, so be sure to do some expectation management and explain that eventually, we will structure it. For process EventStorming, we want to capture domain events of the current state and put them on the white paper in order of time. A domain event, in short, is something that is business relevant that has happened in the domain. We ask them to write down domain events, a pattern later added in the reference book by Eric Evans. We give the participant orange stickies and a marker. Now we can start capturing the current state by doing a process EventStorm. I look for rooms with at least an 8 meters long wall of where I can put a paper roll on, and we definitely need a whiteboard. One important thing here is to find enough modelling space, preferably infinite space (if ever!). It is perhaps wise at this stage to talk to this person before such a workshop and see if we can get some information out, or even better but harder, change this person’s toxic behaviour so that this person can join the workshop. But this person can have a lot of domain knowledge essential for this stage. People who are toxic are killing for a productive workshop, so we might want to decide to leave such a person out. It is vital that we create a safe place in where knowledge can flow freely, a great facilitator can do miracles, but there are limits. We want to be inclusive as possible, but there are exceptions. These are the people who know the domain, the domain experts. It is essential however for the success of this stage to know who the right people are to invite. In just a few hours you can harvest and document a lot of knowledge. As long as there is a storyline to tell, it will be a good starting point.One of my favourite tools to use is EventStorming, a flexible tool when doing collaborate discovery of complex business domain. The starting point for this stage can be several of the following A constraint formed out of a big picture EventStorming A new project or just a user story on the backlog. The primary goals are to collect reference scenarios, capture bits of the model and then leave most ideas behind. If you don’t have a current state and going green field, don’t worry we will get to that part. We start model exploration with harvesting and documenting the current state. In this article, I will tell you my story of how I used the model exploration whirlpool by combining EventStorming, a technique that came from the DDD community, and Example Mapping, a technique from Behaviour Driven Development (BDD) community. Most people when starting to use Domain-driven design (DDD) are looking for these practical examples.
#Domain driven design model how to
While the process itself for most is straightforward and easy to understand, there are not many concrete examples to find on how to do such a model exploration whirlpool. The central theme revolving the process is to keep challenging the model. It is not a development process, but a process that fits in most development processes. The model exploration whirlpool is Eric Evans attempt to capture such advice in writing. People often ask for more concrete guidance on how to explore models, especially in an Agile or Lean setting. This article was published in the leanpub book: Domain-Driven Design: The First 15 Years Introduction