What's in a Name: From Variables to Domain-Driven Design
summary
Argues that names are semantic signs not just labels and shows how Ruby and Rails conventions — pluralization, capitalization, question-mark methods — actually encode intent, uses concrete examples from variables (x vs bit vs bits) and class scope, and cites tools and practices: packwerk, modular monolith, Shopify’s pack findings. Demonstrates domain-driven naming with the Horseless Carriage → automobile example, warns that renames are costly, and gives actionable framing for reorganizing code and reducing semantic debt.
AI-written summary · about
chapters (13)
- 0:00Language and semiotics in software
- 1:06Semiotics to variable naming
- 4:19Meaningful names beyond machine
- 7:30Difference in naming conventions
- 10:00Binary opposition in naming
- 12:11Classes for semantic consistency
- 16:01Semantic shifts in naming
- 18:29Scaling with modular monoliths
- 21:40Functional vs semantic cohesion
- 24:10Semantic debt cost
- 24:52Domain-Driven Design
- 26:15Metaphors for innovation
- 28:04Names for collaboration
related talks
48m“Speak” Your Architecture: From Domain Language to Well-Named Components
31mIs Domain-Driven Design Overrated?
36mWhy It's Worth Arguing for an Hour About Naming in Code Review
44mStrategic Domain-Driven Design for dummies
01h 02mNaming is Hard: Let's Do Better
30m15 Years of Rails With Domain Driven Design - Lessons Learnt
41mDomain-Driven Design: Hidden Lessons from the Big Blue Book
38mWhat I talk about when I talk about Domain Driven design