“Speak” Your Architecture: From Domain Language to Well-Named Components
summary
Argues that naming must be systematic: use a Miro board and a short workshop to collect good/bad names, apply seven quality criteria (consistency, specificity, brevity, austerity, searchability, understandability, pronounceability), map items to stereotypes (commands/queries/events, DDD types) and to color categories (green/pink/yellow/blue), and derive rules like commands as imperatives or “events = past”. Recommends bounded contexts to limit refactors, coordinate API renames across teams, keep a glossary and codified naming rules in the team wiki.
AI-written summary · about
chapters (10)
- 0:00Introduction and speaker intro
- 1:13Why naming matters in software
- 5:37Problems caused by bad names
- 9:53Benefits of good names
- 11:58What needs naming in software
- 13:26Characteristics of good names
- 21:13How to find good names
- 27:37Using categories for naming
- 33:12Monday workshop activities
- 38:07Q&A session
related talks
29mWhat's in a Name: From Variables to Domain-Driven Design
41mThe lost art of software design
01h 02mNaming is Hard: Let's Do Better
45mMake it a thing! - The practice of software architecture
46mPractical (a.k.a. Actually Useful) Architecture
08mLightning talks – 101 Things Software Never Learnt
01h 00mDescribing and Documenting Your Architecture
25mBuilding Castles, Not Sandcastles: Strategies for Software Architecture Success