liveBook · Manning

Collaborative discovery and modeling

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

A collaborative modeling session is a facilitated activity in which participants jointly create or discuss models to reach shared understanding.

Collaborative discovery and modeling is a facilitated, visual way for stakeholders, decision-makers, and software teams to examine complex or conflict-laden problems together. Rather than treating design as a handoff to specialists, participants make their mental models visible, question assumptions, and build shared understanding of the domain, its needs, and possible decisions. section 2.1.2 section 1.0

The visual model is a means, not the outcome. Externalizing a conversation reduces reliance on memory and exposes cases where people use the same word for different concepts. A session should keep attention on discovering the domain rather than mastering notation, using tools that participants can learn, change, and revisit easily. section 2.1.2 section 2.1.3

Use a flexible sequence of stages rather than a rigid process:

  • Prepare by identifying the business problem, relevant stakeholders, decision-makers, and the questions the group needs to explore. section 2.0 section 1.3.2
  • Check in and facilitate the group’s exploration, making perspectives, assumptions, disagreements, and social dynamics discussable. section 1.3.2 section 1.2.5
  • Create and adapt a shared visual model while asking what ambiguous domain words mean and recording assumptions or hotspots. section 2.1.3
  • Check out, retrospect, communicate results, and record decisions so the shared understanding can guide later work. section 1.3.2 section 1.3.4

Model in both problem and solution spaces. In the problem space, visualize user or business needs, goals, tasks, and constraints before jumping to features. In the solution space, develop and compare possible designs; implementation and real-world use can then test which model works best. A solution may also reveal new problems, requiring the group to revisit and update its model. section 2.3.1 section 2.6

Tool choice should serve the conversation. EventStorming can rapidly map business processes through domain events; a Business Model Canvas can examine offerings, customers, infrastructure, and finances; Example Mapping can help break down user-focused work. Useful tools have a low learning curve, support movement and revision, and make their notation legible through a simple legend. section 2.6 section 2.1.3

Resolving an architecture disagreement

A ticketing organization wanted an “Anytime, Anywhere” campaign, but its mobile-unfriendly interface and backend were tightly intertwined. In multiple sessions, stakeholders and team members—including developers with conflicting proposals—made alternatives visible and worked toward a redesign. The resulting boundaries separated the user interface and ticketing system, moved ticketing business logic server-side, and introduced a movie-scheduling service for shared logic. Having decision-makers present helped keep disagreement from becoming personal and reduced later adjustment. section 1.1 section 1.2.2

Facilitation is central because collaboration can stall when conflict, unequal voice, false consensus, or resistance stays hidden. A facilitator need not impose a design or hold a particular job title; the role is to organize conditions for participation, guide dialogue, surface hindering dynamics, and help the group reach supported decisions. Broad participation matters, especially from domain experts, but it also requires stakeholder buy-in and time away from regular work. section 1.2.2 section 1.2.1 section 1.2.5

Turn discoveries into explicit decisions. A shared model lets participants compare alternatives, tradeoffs, and value across technical, social, and cognitive concerns. Document the context, decision, and consequences when needed—for example with architectural decision records and diagrams—but do not mistake documentation for the main result: durable shared understanding that supports adaptable software and team ownership. section 3.1.5 section 1.3.4 section 3.1

Figure 1.1 A collaborative modeling session in which a group of people are visualizing their conversation, enabling them to make better design decisions through shared understanding

Use this session view to discuss the basic setup: a group visualizes its conversation so shared understanding can inform design decisions. section 1.0

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

How deep it goes
Explains definition, visual modeling rationale, tool selection, session stages, social dynamics, and decision follow-up without prescribing a fixed process.
Examples
Uses BigScreen’s modernization conflict, EventStorming for movie extensions, and a Business Model Canvas to make assumptions and domain knowledge visible.
What it assumes
Starts with stakeholder conversations and introduces accessible visual tools, while requiring willingness to examine domain language and assumptions collaboratively.
What you can do after
Apply it to convene relevant participants, visualize assumptions and alternatives, and formalize supported design decisions.
How it connects
Connects domain modeling, stakeholder analysis, facilitation, social dynamics, software architecture, design decisions, Domain-Driven Design, EventStorming, and Business Model Canvas.

Also explained in

Compare how 2 books explain collaborative discovery and modeling →

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.