Intent and Mechanism

The garden’s core reading lens, first cut for DDD. Every DDD pattern is a durable intent wrapped around a dated mechanism. The intent is what the pattern is for; the mechanism is how Evans, in 2003, had you deliver or enforce it. The intent survives every technology shift; the mechanism is the paradigm- and infrastructure-bound part that ages.

A bounded context is almost pure intent (a model-and-language boundary), so it came through object-orientation, ORMs, distribution, and remote teams untouched. An aggregate is an intent (a consistency boundary) welded to a mechanism (one database transaction, one hand-rolled repository), so it looks dated even though its boundary idea is not.

The payoff is diagnostic: most live DDD disagreements turn out to be about mechanism, never intent. Before rejecting a pattern, separate the two and check which one you actually object to. This is the garden’s own framing, crystallized in the DDD audit rather than lifted from one author, and the test desiderata borrow the same split: name the durable goal, leave the contested mechanism off the axis.

Signal: for any pattern you can state its intent in one sentence and its 2003 mechanism in another, and say which has aged. Part of Domain-Driven Design.

Sources

• This lens is the garden’s own, synthesized across the DDD audit rather than taken from a single author.