Collaborative Software Design How to facilitate domain modeling decisions (Evelyn van Kelle, Gien Verschatse etc.)（Z-Library）

【One-Line Pitch】 A practical guide to running collaborative modeling sessions that align stakeholders around domain decisions before code gets written. Best for software architects, tech leads, product people, and anyone who facilitates design conversations across business and engineering. 【Book Arc】 - **Opening (~0%–10%)**: Frames the core problem—teams build the wrong software because design decisions are made implicitly and top-down—and introduces collaborative modeling as a visualization technique to create shared understanding among all stakeholders. - **Early (~10%–30%)**: Connects collaborative modeling to Domain-Driven Design, walks through tools like Business Model Canvas, EventStorming, and Domain Storytelling, and reframes technical debt as a conscious architectural decision rather than mere cruft. - **Middle (~30%–50%)**: Moves into facilitation practice: preparing sessions, using heuristics, managing group dynamics through check-ins, check-outs, sensemaking, and techniques like Small Group Diverge and Converge. - **Late (~50%–70%)**: Explores the facilitator's role and core competencies—Neutrality, Observing, and Compassion—along with ranking theory and how status differences shape who speaks and who stays silent. - **Ending (~70%–100%)**: Addresses cognitive bias, resistance, conflict resolution, and follow-up practices including documenting sessions and reporting outcomes to stakeholders. (Excerpts do not cover the final chapters in detail.) 【Key Takeaways】 - **Everyone involved in software creation is a designer** (Opening): The book deliberately widens the definition of "designer" beyond architects and developers, arguing that business stakeholders, testers, and analysts all shape design outcomes and should be included in modeling sessions. - **Collaborative modeling is a visualization technique for complex, conflict-laden decisions** (Opening): It is not just drawing diagrams—it is a structured way to surface different mental models, create shared understanding, and make implicit assumptions explicit before they harden into architecture. - **DDD and collaborative modeling reinforce each other** (Early): DDD provides patterns and principles but no prescribed method; collaborative modeling fills that gap by giving teams practical visual tools to build ubiquitous language and identify domain boundaries. - **Technical debt is a conscious decision, not just bad code** (Early): The authors distinguish explicit architectural trade-offs (knowingly taking on debt for speed) from implicit design decisions that produce unintended cruft—and argue the former is manageable while the latter breeds frustration and risk. - **Facilitation is a learnable skill built on three competencies** (Middle): Neutrality, Observing, and Compassion can be developed by anyone, regardless of job title, and are supported by holding space, active listening, and clear communication. - **Heuristics guide facilitation but are never complete** (Early–Middle): The book offers guiding heuristics—such as splitting a subgroup during diverging conversations or discussing conflict with the whole group—while stressing that facilitators should adapt and add nuance over time. - **Check-ins and check-outs protect group dynamics** (Middle): Especially after intense sessions, a deliberate closing ritual prevents negative emotions from lingering, reduces gossip, and helps participants feel connected to the outcomes. - **Ranking and cognitive bias shape who contributes** (Late): Status differences and unconscious biases determine whose voice is heard; making these dynamics explicit is part of the facilitator's job, not a distraction from it. 【Reading Tips】 - **Deep-read the facilitation chapters** (roughly the middle third): The preparation templates, heuristics, and group techniques are the most immediately actionable parts—bring them to your next workshop. - **Skim the DDD and tool overviews if you already know EventStorming or Domain Storytelling**: Use them as a reference for choosing the right tool rather than reading linearly. - **Pay attention to the case study thread (BigScreen)**: It runs through multiple chapters and shows how the same team applies, struggles with, and benefits from collaborative modeling over time. - **Treat the conflict and bias chapters as a toolkit, not theory**: The value is in the specific questions and exercises—like "Who can somewhat relate to this?"—that you can use verbatim. - **Don't skip the follow-up practices**: Documenting sessions with version control and timestamps is unglamorous but is what makes collaborative design sustainable beyond a single workshop. 【Coverage Limits】 This guide is based on stratified excerpts covering roughly the first half to two-thirds of the book. The later chapters on conflict resolution, cognitive bias, and detailed follow-up practices are referenced but not fully represented in the source material.