liveBook · Manning

Continuous improvement

As explained in Collaborative Software Design: How to facilitate domain modeling decisions

A cycle in which information about outcomes or requirements feeds back into subsequent decisions or actions.

A feedback loop turns design into an ongoing cycle: gather information, challenge the current model, adjust decisions, and repeat. It replaces the assumption that discovery, strategy, and implementation form a finished linear sequence. section 11.3 section 11.3.1

The loop matters because decisions are made under uncertainty. New perspectives, conversations, conflicts, biases, requirements, and implementation conditions can all reveal that the model needs revision. Treat models, designs, and decisions as living artifacts rather than possessions. section 11.3 section 11.3.1

Use the loop to keep collaborative modeling responsive:

  • Revisit discovery with new or different participants; a single EventStorming session rarely captures the whole current state. section 11.3.1
  • Let the model settle, then share it beyond the original modeling group to invite further perspectives and iterations. section 11.3.1
  • Use conversations, conflicts, and explicit biases as evidence for revising the model, not as disruptions to avoid. section 11.3.1
  • Keep decisions and models current through ADRs, asynchronous comments, distilled diagrams, and other living documentation. section 11.3 section 11.7
  • Discard or redesign a model when new information makes it unsuitable; attachment, sunk costs, and model-fitting can prolong a poor decision. section 11.3 section 11.7

A modeling whirlpool

A team begins by exploring the current state, organizes its understanding, and moves toward implementation. Instead of stopping there, it invites additional participants, revisits the model after reflection, shares it with outsiders, and changes it when new requirements or disagreements surface. The resulting process loops through discovery, modeling, communication, and redesign. section 11.3.1

Figure 11.7 Model Exploration Whirlpool from Eric Evans. This whirlpool helps in considering collaborative modeling as a collection of feedback loops, rather than a linear process. (Source: www.domainlanguage.com/ddd/whirlpool/)

Use the Model Exploration Whirlpool to visualize collaborative modeling as interconnected feedback loops rather than a linear delivery path. section 11.3.1

How Collaborative Software Design: How to facilitate domain modeling decisions covers it

How deep it goes
Explains iterative modeling, participant changes, reflection, sharing, and redesign, but stops short of prescribing a fixed loop or cadence.
Examples
Uses repeated EventStorming, asynchronous decision comments, distilled diagrams, and Eric Evans’s Model Exploration Whirlpool.
What it assumes
Assumes familiarity with collaborative modeling and decision records while treating iteration, uncertainty, and model revision as central practices.
What you can do after
Apply iterative modeling to gather evidence, lower uncertainty, challenge assumptions, and revise decisions without preserving unsuitable designs.
How it connects
Connects feedback loops with ADRs, living documentation, EventStorming, Behavior-Driven Development, Example Mapping, and collaborative modeling.

Also explained in

Compare how 30 books explain continuous improvement →

Related concepts

This explainer was generated by Manning's knowledge graph from the text of Collaborative Software Design: How to facilitate domain modeling decisions. The section links point to the parts of the book it draws on.