Terminology Mismatch Repair Made Plain
summary
Practical method for finding and fixing domain word conflicts: a three‑step R3 (recognize, resolve, rectify) process plus a worksheet called the Terminology mismatch map to collect terms, definitions, implemented behavior and industry meanings. Concrete moves include event‑storming/mind‑mapping to surface usage, turning fixes into tracked backlog tasks, using the strangler pattern and anti‑corruption layers when a monolith embeds wrong meanings, and tooling like Contex for VS Code. A Payfit pay period case study shows clarifying a single term creates decoupling, team autonomy and product evolution.
AI-written summary · about
chapters (16)
- 0:00Introduction
- 3:40Legacy software confusion
- 7:16Why terminology matters
- 10:06R3 process for repair
- 15:46Resolving conflicts
- 21:06Communication skills
- 24:18Terminology in driving habits
- 27:26Avoiding fake knowledge
- 28:53Tools for domain semantics
- 36:45Conflicting terms handling
- 41:05Global team alignment
- 43:14Refactoring wrong definitions
- 45:40Prioritizing changes
- 47:25Codebase language
- 49:16Cross-language mismatches
- 50:40Q&A
related talks
40mFrom Domain Boundaries to Software Architecture
54mFrom Domain Boundaries to Software Architecture
01h 11mAn introduction to DDD
37mBuilt to last: A domain-driven approach to beautiful systems
31mOoops! You named it wrong. What now?
25mHow to use Example Mapping and 3 amigo sessions to shift left
01h 01mDomain-Driven Refactoring
47mGetting modules right with Domain-driven Design