Module 3: Domain-Driven Design & Bounded Contexts: Mistake Clinic

This clinic turns wrong moves into reusable judgment. Use it after each practice page and again before the quiz or checkpoint.

---

Module-Specific Mistake Radar

Start with these traps. Replace or extend them with real mistakes from your own work.

Mistake to look for	Where it shows up	Symptom	Repair evidence
Finishing Strategic Design Lab with only a final answer	Strategic Design Lab	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing Context Mapping Workshop with only a final answer	Context Mapping Workshop	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing EventStorming Clinic with only a final answer	EventStorming Clinic	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Finishing DDD Tactical Katas with only a final answer	DDD Tactical Katas	The work has no failed case, trace, test, proof gap, or design stress point.	Add the smallest broken example and show the repair that changes the result.
Treating Domain, Subdomain, Bounded Context: The Three-Level Split as vocabulary instead of a tool	Domain, Subdomain, Bounded Context: The Three-Level Split	The explanation names the concept but cannot decide between two cases.	Write one example, one non-example, and the rule that separates them.
Treating Core, Supporting, and Generic Subdomain Classification as vocabulary instead of a tool	Core, Supporting, and Generic Subdomain Classification	The explanation names the concept but cannot decide between two cases.	Write one example, one non-example, and the rule that separates them.

---

Practice Mistake Checks

Pull any miss from these checks into your mistake log.

Strategic Design Lab

Source: practice/01-strategic-design-lab.md

Identify the error in each:

1. "We have one core subdomain and eight generic ones, so we will outsource everything except the core."
2. "Pricing and Rating are two bounded contexts because we have two services for them."
3. "The business domain is 'logistics'; our subdomain is 'shipping' and our bounded context is 'shipping.'"
4. "We wrote down the ubiquitous language in a Confluence page; that was the language definition step."
5. "Our supporting subdomain uses the same model as our core subdomain because both deal with customers."
6. "Core means important. Everything important is core."
7. "Our startup has three core subdomains and no supporting or generic ones."
8. "Customer means the same thing in every context; we share a Customer class across services."

Context Mapping Workshop

Source: practice/02-context-mapping-workshop.md

Identify the error in each:

1. "We share a models/ package between the Shipping and Billing contexts so we can reuse the types. It's just a utility library."
2. "The carrier's API is ugly, so we built an ACL on the carrier's side."
3. "Two teams are partnering, so we do not need coordination for breaking changes."
4. "Our OHS is stable because it's OpenAPI 3.1 and we have a schema."
5. "We don't need a context map -- each team documents its own API."
6. "The ACL translates JSON; it's just a JSON parser."
7. "We use REST so we have an Open Host Service by definition."
8. "If two contexts are in conformist, that means the downstream likes the upstream."

EventStorming Clinic

Source: practice/03-eventstorming-clinic.md

Identify the error in each:

1. A sticky note reads Row inserted into shipments table.
2. The team skips the 10 minutes of silent chaos writing because "we already know the process."
3. A policy sticky note reads Shipping service calls the billing API.
4. Every event is followed by exactly one command in the same color.
5. The facilitator is also the tech lead for the team and keeps intervening to clarify.
6. Three engineers and no domain experts are in the room.
7. After the session the board is photographed and never used again.
8. Design-level EventStorming skips red hot-spots because "we want progress."

---

Repair Protocol

For each real mistake:

1. Reproduce the failure on the smallest example, trace, proof, query, command, or design sketch.
2. Name the hidden assumption.
3. Repair the artifact.
4. Save evidence that changed: failing then passing test, corrected proof step, revised diagram, safer command, benchmark, or review note.
5. Add one retrieval card beginning with Check... before... or Do not use... when....

---

Mistake Log

Date	Mistake	Symptom	Root cause	Repair evidence	Retrieval card
Starter	Pick one radar row above	Explain how it would fail in this module	Name the assumption	Add a counterexample or corrected artifact	Write the card before closing the page

---

Completion Standard

• At least five real mistakes are logged.
• At least two mistakes include a counterexample or failing test.
• At least one mistake connects to an older semester skill.
• At least one correction changes code, a proof, a diagram, a command transcript, a query, or a design decision.