Domain-Focused Naming

Domain-focused naming prioritizes what code represents in your business problem over how it's built. Instead of `ZodValidator` or `JSONParser`, name elements by their purpose: `ConfigValidator`, `UserParser`. This keeps names stable as implementations change and makes code more intuitive for team members unfamiliar with specific technical choices.

Temporal context in names becomes misleading and stale quickly. `ImprovedHandler` or `NewUserService` confuse developers months later when the code is neither new nor improved relative to other code. Domain-focused names like `UserService` and `EventHandler` remain accurate and clear regardless of when they were written.

Name code elements after what they represent in the domain, not implementation details or internal mechanics. Use domain language: `Order`, `ProcessPayment`, `CustomerAccount` instead of `Obj1`, `HandleData`, `TempCache`. Names that read like domain-language phrases make code self-documenting and reduce cognitive load during reviews and maintenance.

Apply domain-focused naming whenever you define or modify code elements: during initial development, code reviews, refactors, and API design. Review names that expose implementation details, temporal context, or pattern names. Renaming early prevents confusing or outdated names from spreading through the codebase.

Names that hide technical specifics make code more durable and team-friendly. When names don't expose protocols, data formats, or library choices, you can swap implementations without renaming everywhere. This reduces friction during refactors and lets developers focus on domain logic rather than technical archaeology.

Yes. Domain-focused naming applies consistently to variables, functions, classes, modules, and APIs. The principle—reflect domain semantics, not implementation—works across naming contexts. Apply it during code reviews to catch vague names, during refactors to clarify purpose, and during API design to ensure public contracts communicate intent clearly.