Naming Guide

General Rules

• Use the language of the business, not implementation shorthand.
• Prefer specific names over generic names.
• Avoid names that only describe a database operation unless the model is intentionally CRUD.
• Use the same term consistently inside a bounded context.
• Use hotspots when two terms may mean different things.

Commands

Name commands as imperative verb phrases.

• Good: Approve Claim, Reserve Inventory, Schedule Appointment, Change Subscription Plan.
• Weak: Claim Approved, Update Record, Save, Submit, Process.

Domain Events

Name events in the past tense because they record facts that happened.

• Good: Claim Approved, Inventory Reserved, Appointment Rescheduled, Payment Failed.
• Weak: Approve Claim, Inventory, Payment, Status Changed.

Aggregates

Name aggregates as business nouns that own decisions and consistency.

• Good: Order, Claim, Subscription, Appointment, Route Assignment.
• Weak: OrderTable, ClaimData, SubscriptionManager, AppointmentService.

Policies

Name policies so the trigger and intent are understandable.

• Good: Reserve Inventory After Payment, Suspend Entitlements After Dunning Deadline.
• Weak: Payment Handler, Policy 1, Background Job, Event Processor.

Read Models And Queries

Name read models around the decision or display they support. Name queries as questions or search actions.

• Good read model: Claims Awaiting Review, Customer Order Status, Driver Route View.
• Good query: Find Available Slots, Show Claims Awaiting Review, Get Account Billing Summary.
• Weak: ClaimDto, DataView, GetStuff, Search.

Bounded Contexts

Name bounded contexts after business capabilities, not technical layers.

• Good: Billing, Fulfilment, Claims Assessment, Entitlements, Dispatch.
• Weak: Database, Backend, Microservice 1, Shared, Common.