1. Home
  2. Writing
2 min readDDDGo

Event storming a healthcare product with nurses in the room

How a wall of sticky notes turned into Go services, a message bus and a nurse panel — and why the domain experts mattered more than the diagram.

Colourful sticky notes pinned to a board
Photo: @patrickperkins / Unsplash

As CTO of Hoivalani, a home-visit and family healthcare product in Finland, I started with a wall, not a codebase. The team was four developers, three designers and two nurses. The nurses turned out to be the most important people at that wall.

Why event storming

Healthcare has a vocabulary that developers think they know and don’t. A “visit” can mean the plan, the trip, the time in the home or the paperwork afterwards. Event storming forces those differences into the open, because everyone has to write what happens, in the past tense, on a sticky note, in front of everyone else.

The session, step by step

  1. Chaos. Everyone writes domain events, one per note, in the past tense: visit scheduled, nurse arrived, visit documented. No discussion yet.
  2. Timeline. Put them in order. Duplicates and disagreements show up immediately.
  3. Hot spots. Mark every place where someone said “it depends”. That is where the product is.
  4. Commands and actors. Who or what causes each event? A nurse, a coordinator, a family member, a timer?
  5. Boundaries. Draw lines where the language changes. Those lines are your bounded contexts.

From the wall to the code

The mapping from the wall to the architecture was more direct than I expected:

  • Each bounded context became a Go service with a hexagonal layout: the domain in the middle, adapters for HTTP, Postgres and the broker at the edges.
  • The domain events became messages on RabbitMQ. The names on the wall are the names in the code.
  • The views people needed — “my visits today”, “who is where right now” — became CQRS read models, built from those events and shaped for one screen each.
  • Live location got its own context. It changes every few seconds, and nothing else in the system should have to care.

The nurse panel, a React app with live location tracking, was mostly a consumer of read models. That kept it fast and kept the business rules out of the frontend.

What I would tell myself before the first session

  • Put the people who do the work in the room. Two nurses at the wall are worth more than a month of requirements documents.
  • Use their words. If the nurses say “visit report”, the type is not called EncounterSummary.
  • Stop when the boundaries are clear, not when the wall is pretty. The wall is a draft. The code will teach you the rest.
  • Photograph everything. The wall comes down; the decisions shouldn’t.

Event storming is not a diagramming technique. It is a way to get a mixed team to agree on what the product does before anyone argues about how. In healthcare, where a misunderstanding reaches a patient, that agreement is most of the job.

More writing

All writing
tahersoft.com

Case studies, retros and the podcast live on TaherSoft.

Does your product need a CTO-shaped person?

Right now: writing case studies, recording the first podcast season, open to CTO / staff-engineer roles.