What is the Cohesive Mechanisms pattern in DDD core-domain distillation, and how does extracting a computational mechanism differ from extracting a Segregated Core?

## What it separates **Cohesive Mechanisms** is a distillation technique that targets a different kind of tangle than separating core from generic code does. Where that other technique separates code by **domain significance** — pulling the highest-value, most differentiating model out from the generic and supporting code around it — Cohesive Mechanisms separates code by **kind of responsibility within the core domain itself**: it isolates a self-contained, well-defined computation from the surrounding domain objects that express business intent, giving that computation its own focused component behind a small, deliberately narrow interface. Such a computation might be: - a constraint solver - a route-finding or scheduling algorithm - a pricing or discount rule engine - a matching algorithm Mechanically, the move looks like this. You notice that: 1. several entities or services in the core model have accumulated substantial procedural logic to answer a 'how do we compute X' question; 2. this logic is large enough to obscure the domain concepts around it; 3. it can be described independently of any specific business rule — it's a general capability, such as finding the shortest or cheapest path or finding an assignment satisfying a set of constraints, that the domain configures rather than something the domain fundamentally is. You then extract that capability into its own module with a published interface — the mechanism takes structured inputs and constraints and returns a structured result — and the surrounding core model is rewritten to invoke that interface declaratively, freeing its own classes to read as expressions of domain meaning again. ## Why it exists The reason this exists is that even inside a properly identified and segregated core domain, complexity does not distribute evenly, and a chunk of that complexity is often **algorithmic rather than conceptual**. A shipping company's core domain genuinely is about cargo, routes, transfers, and customer commitments, but the actual work of finding a legal, cost-effective multi-leg route through a graph of ports and carriers under time-window constraints is a computer-science problem, essentially a constrained shortest-path search, not a business concept anyone would describe in domain-expert language. Left inline, that algorithm's loops, priority queues, and backtracking logic get interleaved with domain classes, and the resulting code is hard to read as either good algorithm code or a clear expression of the domain. Extracting it as a cohesive mechanism lets each side specialize: - **the mechanism's code** can be reasoned about, tested, and optimized purely as an algorithm, with its own unit tests against abstract inputs; - **the domain model** expresses only what needs to be computed and why, in vocabulary the domain expert would recognize. ## Getting the seam right The trade-off is the cost of designing and holding a genuinely clean interface between declarative 'what' and imperative 'how'. Getting this seam right is harder than it sounds: | Seam | What goes wrong | |---|---| | **too narrow an interface** | the mechanism can't express real business constraints without the domain model reaching around it to hand-roll edge cases | | **too wide, or too tied to the mechanism's internal data structures** | the extraction is superficial — the domain model still has to understand the mechanism's internals to use it correctly, which defeats the purpose | There's also an ongoing cost of keeping two different design vocabularies coherent: the domain model's classes are meant to read like business language, while the mechanism's classes are meant to read like algorithm language, and someone has to maintain the fluent translation between the two every time either side changes. ## Failure modes 1. The characteristic failure mode is a **leaky mechanism boundary**: the extracted route-finder starts clean, but over successive feature requests — such as needing to avoid a specific port for one customer's contract or giving one carrier priority on certain days — the mechanism's interface grows special-case parameters that are really business rules smuggled into what was supposed to be a generic algorithm, until the mechanism is neither reusable nor readable, and the domain model has lost the declarative clarity the extraction was meant to buy back. 2. A second failure mode is **extracting a mechanism too early or unnecessarily** — turning a genuinely simple, domain-specific calculation, such as a straightforward percentage discount, into an over-engineered mechanism component adds interface and indirection cost without a matching payoff, because there was no real algorithmic complexity to hide in the first place. 3. A third is **confusing this technique with core-versus-generic separation** and expecting it to solve a domain-significance problem — extracting a mechanism from generic code doesn't make that code core, and a mechanism sitting inside an un-segregated core doesn't protect the core's boundary from the rest of the system; the two techniques address orthogonal axes and are often applied together, not as substitutes. ## A concrete example A concrete, well-known example is a shipping application whose core domain expresses itineraries, legs, and customer commitments declaratively, while a separately designed **routing mechanism** — essentially a specialized pathfinding engine over a graph of transport legs subject to constraints — is invoked to actually compute a legal itinerary, keeping the constraint-solving machinery out of the domain classes that describe what a valid shipment commitment even means.