Why are Domain Services in DDD expected to be stateless, and what specifically breaks in production if a team adds mutable instance fields to one?

## What statelessness means here Statelessness for a Domain Service means the object holds **no mutable data between one method call and the next** - every fact the operation needs must arrive: - as a method parameter - or through an injected collaborator (like a repository) that is itself only used to read or persist data, not to accumulate state on the service instance This is a deliberate constraint, not an accident of style: it is what makes a domain service behave like a **pure function over domain objects** rather than like an entity with its own lifecycle. Contrast this with an entity, which is expected to hold state (an `Order` legitimately remembers its own line items and status) - a domain service is explicitly the opposite kind of object, and conflating the two by giving a service its own evolving fields undermines the reason it was introduced in the first place. ## Why it matters in a real deployment The practical reason this matters comes from how domain services are actually deployed in real applications. In almost every modern backend, dependency-injection containers (Spring, .NET's built-in DI, and equivalents) wire services up as **singletons by default** - one instance of the class serves every request for the lifetime of the application. If that single instance has a mutable field, say a `cachedExchangeRate` or a `runningTotal` set during one call, then every subsequent concurrent call sees and can overwrite that same field. Under load, two requests running on different threads can genuinely interleave: 1. request A sets the field 2. request B overwrites it before A reads it back 3. and A completes using B's data This produces a **race condition**, and race conditions are notoriously hard to catch in code review or in simple tests because they: - only manifest under concurrent load - disappear when you add a debugger breakpoint (which serializes execution) - and often show up in production as sporadic, unreproducible data corruption rather than a clean crash ## What the constraint costs and buys The trade-off is mostly one-sided in production code: statelessness costs a small amount of parameter-passing verbosity (you sometimes have to thread a value through a call rather than stash it on the object once), but buys **thread safety for free**, since a stateless object has nothing to corrupt no matter how many threads call it concurrently. - It also buys **simpler testing**: a stateless service test needs no setup/teardown of internal fields between test cases and can reuse a single instance across the whole suite without contaminating results; a stateful one risks test-order-dependent failures, where a test passes in isolation but fails when run after another test left the service in an unexpected internal state. - And it buys **straightforward horizontal scaling**: since no server-local memory holds business state, any instance behind a load balancer can serve any request, which matters once an application runs on more than one process or machine. ## Failure modes The failure modes when a team violates this are recognizable. 1. **The most direct is the race condition already described** - intermittent wrong answers or crossed data under concurrent load, often first noticed in production under peak traffic rather than in development. 2. **A subtler one is accidental cross-request memory retention**: a mutable field holding a reference to, say, a large object from one request can keep it alive longer than intended, contributing to memory bloat or, worse, letting data from one tenant or user leak into a response for a different one - a serious problem in multi-tenant systems. 3. **Another is 'my tests are flaky' bug reports** that turn out to be caused by shared mutable state on a domain service instance reused across test cases, wasting engineering time chasing a phantom test-infrastructure bug when the real defect is the service's own design. ## A concrete illustration A concrete illustration: imagine a `PricingService` with a method `calculateFinalPrice(Order order, Discount discount)` that, for a misguided 'optimization,' caches the last discount it computed in a field named `lastDiscount` so a subsequent debug log can print it. Under moderate concurrent traffic, two customers checking out within milliseconds of each other can end up with each other's discount applied to their order - a bug that would sail through single-threaded manual testing and appear only once concurrent load exists, exactly the kind of defect that's expensive to diagnose after the fact because the cause (a stray mutable field) is far from where the symptom (wrong price charged) shows up.