What's in a Name: From Variables to Domain-Driven Design
summary
Argues that naming is semiotics not style and demonstrates specifics: Rails copies controller instance variables into views so variable names must carry intent, pluralization capitalization and punctuation change meaning, and binary oppositions couple values. Shows tooling and outcomes: uses Packwerk and pack-based modularization, cites Shopify’s retrospective where teams adopted packs and chose functional coupling over semantic grouping, and warns that large-scale renames are costly and slow to work through.
AI-written summary · about
chapters (7)
- 0:00Language and semiotics in software
- 3:57Naming is harder than it seems
- 10:00Difference creates meaning in code
- 14:16Binary opposition and evolving signs
- 18:29Organizing code beyond MVC
- 23:49Semantic debt and DDD
- 26:15Metaphors and new domains
related talks
37mBuilt to last: A domain-driven approach to beautiful systems
26mEven Naming This Talk Is Hard
58mDDD really matters!
52mVariables of the Veracious Variety: How to Better Name your Variables
38mDomain-Driven Design: Hidden Lessons from the Big Blue Book
50mIt's All About the Domain, Honey - Domain-Focused Architecture with DDD
01h 11mAn introduction to DDD
39mDomain-Driven Design: Hidden Lessons from the Big Blue Book