When designing a Domain Service, how should the ubiquitous language guide its name and method signatures, and what's the tell-tale sign that you've actually built a technical helper class wearing a domain costume?

## What the ubiquitous language is The ubiquitous language is the vocabulary that developers and domain experts agree to use consistently, in conversation and in code, so that a class, method, or variable name means the same thing to both groups. For a Domain Service this discipline is **not cosmetic** - naming is the primary signal of whether the service actually represents a coherent domain concept or is just a bucket for code that didn't fit anywhere else. A well-named domain service reads like a sentence from a requirements conversation: - 'transfer funds between accounts' becomes `FundsTransferService.transfer(from, to, amount)` - 'check that this email isn't already registered' becomes an `EmailUniquenessChecker` or similar If a domain expert would frown at the class name or ask 'what does that mean?', that's a signal the abstraction was invented by the code, not discovered in the domain. ## The method signatures carry it too This extends past the class name into the method signatures. A domain service that takes `String email` and `long accountId` as parameters, rather than an `Email` value object and an `AccountId` or `Account`, has usually lost its connection to the model - it's operating on primitives the way a database access layer would, not on the rich types the ubiquitous language defines. Keeping domain types in the signature is what: - lets the service compose naturally with the rest of the model (an `Email` value object can enforce its own format invariant, so the service doesn't have to re-validate a raw string) - keeps the service's purpose legible from its type signature alone ## Why the name carries so much weight The reason this matters so much is that a Domain Service, unlike an entity, has **no natural anchor** - it doesn't own persistent state or an identity that forces a coherent boundary around it. An entity's responsibilities are bounded by what data it holds; a domain service's responsibilities are bounded only by what its author decides to put in it, which makes discipline in naming and scope the only thing standing between 'a clean stateless domain operation' and 'a junk drawer.' Naming from the ubiquitous language forces that discipline: | A name like | What it invites | |---|---| | `OrderProcessingService` | vague enough to justify adding almost anything | | `BackorderReplenishmentPolicy` | specific enough that an unrelated method addition would visibly not belong | ## The trade-off The trade-off is that finding the right name takes real conversation with domain experts and iteration - it is genuinely slower than reaching for a generic '...Service' or '...Manager' suffix, and teams under deadline pressure often skip it. The cost of skipping it doesn't show up immediately; it shows up six months later when: - the `OrderManager` class has forty methods - ten different developers have each added 'just one more thing that's kind of related to orders,' - and nobody can describe what the class is responsible for in one sentence At that point the service has become what Martin Fowler and others call a **'God class'** or, in DDD terms, evidence that the domain model has become anemic - because if `OrderManager` does everything an `Order` could ever need done to it, the `Order` entity itself has been reduced to a data holder. ## The concrete tell-tale signs The concrete tell-tale signs to watch for in review are: 1. suffixes like `Manager`, `Helper`, `Util`, or `Processor` that describe a technical role rather than a business process 2. methods on the same class that have nothing to do with each other conceptually (e.g., `calculateDiscount` and `sendConfirmationEmail` on the same `OrderService`) 3. parameters that are primitives or DTOs instead of domain objects 4. and an inability, when asked, to state the service's single responsibility as one sentence using words a business stakeholder would use A useful concrete example of doing it right: in a shipping domain, instead of a `ShippingManager` with a `computeCost` method buried among a dozen others, a `ShippingCostCalculator` (or, if the rule is really a pure function of a `Package` and a `Destination`, arguably a method on a `ShippingQuote` value object) keeps the name, the scope, and the vocabulary aligned with what the business actually calls the concept - which is the entire point of grounding the design in the ubiquitous language rather than in implementation convenience. ## A name is a hypothesis One more practical wrinkle worth naming: the ubiquitous language is not fixed once and for all - it evolves as the team's understanding of the domain deepens, and a domain service's name should evolve with it. If, during a modeling session, the team realizes that what they've been calling `PricingService` is really two distinct concepts - a `DiscountPolicy` and a `TaxCalculator` - the correct response is to rename and split, even though that touches every caller. Treating a domain service's name as permanent, rather than as a hypothesis to be refined, is itself a way naming discipline erodes over time; the healthiest teams revisit service names during retrospectives on the model, not just during initial design.