Collaborative Design

Overview

The artifacts are defined. Somebody has to produce them, and the good ones are not produced alone — not because collaboration is virtuous, but because the knowledge required is distributed across people who do not write documents.

The domain boundaries in particular live with the people who handle the work, and no amount of reading the code recovers them.

Event Storming

A facilitated session that discovers a domain by enumerating what happens rather than what exists. Alberto Brandolini’s technique, set out in Introducing EventStorming.

The mechanic: participants write domain events — things that occurred, in the past tense — on individual notes, and arrange them on a long timeline. Then the group clusters them, finds where clusters stop talking to each other, and names the boundaries.

Why it works better than interviewing: people who do the work cannot usually describe their domain model, but they can reliably tell you what happens and in what order. Events are the vocabulary non-engineers already have.

Three properties that matter architecturally:

It surfaces boundaries nobody articulated. Where events cluster and the clusters communicate rarely, there is a candidate service boundary — derived from the domain rather than from who extracted which slice first.

It surfaces disagreement cheaply. Two people placing the same event at different points in the timeline is a finding. It usually means two different processes are running under one name.

It puts non-engineers in the room on equal terms. Nobody is at a disadvantage, because the medium is “what happens”, not notation.

Bounded contexts

Eric Evans’s term, from Domain-Driven Design, and the reason Event Storming output is architecturally useful: a bounded context is a boundary within which a model is consistent. The same word means different things on either side of it, legitimately.

That reframing resolves a lot of pointless modelling argument. Two teams arguing about what “customer” means are usually both right within their own context, and the correct answer is a boundary with an explicit translation across it rather than one canonical definition imposed on both.

It is also an organisational tool, which is where Module 8 rejoins. A bounded context is a candidate team boundary, and Conway’s Law means the two will converge whether you intend it or not. Designing contexts without looking at who owns them produces boundaries that erode — exactly the prediction Module 8’s analysis made about the two-service split.

Running a session that ends in decisions

The characteristic failure is a productive, enjoyable three hours producing a wall of notes and no decision. Four things prevent it:

graph TD
  A["<b>State the question</b><br/>before the session,<br/>in one sentence"] --> B["<b>Timebox discovery</b><br/>then stop adding<br/>and start cutting"]
  B --> C["<b>Converge in the room</b><br/>name boundaries while<br/>everyone is present"]
  C --> D["<b>Leave with decisions<br/>and owners</b><br/><i>and open questions<br/>named as such</i>"]

  classDef prep fill:#5B8FB9,stroke:#4A7A9E,stroke-width:2px,color:#ffffff
  classDef mid fill:#E8A33D,stroke:#C4832A,stroke-width:2px,color:#ffffff
  classDef out fill:#7D9A4E,stroke:#5F7A38,stroke-width:2px,color:#ffffff
  class A prep
  class B,C mid
  class D out

Four facilitation moves. The third is the one that gets skipped, because convergence is uncomfortable and divergence is fun.

State the question in one sentence before the session. “Where are the boundaries in the support domain?” is a session. “Let’s do an Event Storming” is a workshop with no exit condition.

Timebox discovery. There is always another event to add. At the agreed point, stop adding and start cutting — the interesting information is in the clusters, not in completeness.

Converge in the room. Naming boundaries while the people who disagree are present is the entire value. Taking the notes away to “synthesise” means the synthesis is one person’s opinion with the appearance of group consensus, and the disagreements that were visible on the wall are quietly resolved by whoever holds the pen.

Leave with decisions, owners, and named open questions. An open question recorded as open is fine. An open question that everyone believes was settled is the thing that resurfaces in three months.

Cross-review

The habit that distributes architectural judgement rather than centralising it: engineers and architects reviewing each other’s designs against stated criteria.

It solves a problem Module 8 identified — a single architect becomes a bottleneck, and then a single point of failure. Cross-review builds the judgement elsewhere in the organisation, which is the only durable fix.

It needs two things to work. Stated criteria, or review collapses into taste, and taste disputes are unresolvable and corrosive. And reviewing against the design’s own goals rather than against the reviewer’s preferred approach — the useful question is “does this meet its stated requirements?”, not “is this how I would have done it?”.

One session, one question, and the boundary it found

The support domain has never been modelled. The twenty Go services were extracted in migration order, and Module 8’s Conway analysis established the boundaries reflect extraction sequence rather than the domain.

The question for the session, in one sentence: where does the support domain actually divide?

Who is in the room. Grace Adeyemi and two senior support agents, because they are the only people who know what happens. Priya Shah for product. One engineer from the migration. Deliberately not Tomas Beck or Dev Raghunathan — this is a discovery session, and a VP in the room changes what junior people say.

What the events reveal. The timeline divides naturally at a point nobody had articulated: everything up to “customer’s question was answered” involves only information, and everything after “a change was requested” involves state. The clusters barely communicate — the second needs the first’s conclusion and nothing else.

Which is the two-service split from Module 3, derived independently from the domain rather than from the blast-radius argument. That convergence is worth a great deal: a boundary justified on two independent grounds is far more likely to survive, and it is a materially stronger line in the ADR than either argument alone.

The disagreement that was the real finding. Two agents place “a credit was issued” at different points. It turns out there are two processes under one name — a goodwill credit any agent can issue, and a contractual adjustment requiring finance approval. Module 5’s action tiers had treated credits as one tier. They are two, and the tiering is wrong until the ADR and the action list are corrected.

What leaves the room. Two decisions with owners: the domain boundary is confirmed and recorded, and the credit action is split into two tiers. One named open question: whether device operations belong in the action context or in the device team’s, which nobody present can settle and which is recorded as open rather than assumed.

Feeds the workbook

The boundaries you confirm here belong in the HLD, and any correction a session produces belongs in the ADR set — including the record that supersedes an earlier decision.

Check your understanding

1. Write the one-sentence question for a session you would actually run. What would make the session a failure?
2. Two people disagree about what a core domain term means. How does the bounded-context framing change the conversation?
3. Who would you deliberately exclude from a discovery session, and what does their presence cost?

---

→ Sessions produce decisions. Decisions have to live somewhere that stays current. — Documentation as Code