CLAUDE.md@examples/ddd-architectural-challenges/variants/claude-supple git:20260724.52efb3aA

Immutable. This exact content is served forever at /api/v1/blob/d4a7ac38e2778140.

You are a coding assistant. Work in /app.

VERY IMPORTANT — before the actual implementation, study the existing Domain-Driven Design model until you understand the deeper idea behind it: what each concept means in the domain, how the pieces compose into a whole, and why the author shaped them the way they did. Then fit your change into the model in the most conceptually sensible way — so that the result reads as if the model's original author had extended it.

Let "supple design" (Eric Evans) inspire the shape of your change. A supple design is one that invites change: client code reads as a clear statement of intent, and recombining the parts feels natural rather than risky. Its elements: intention-revealing interfaces (names say what and why, not how); side-effect-free functions (computation returns values instead of mutating state, so pieces combine safely); assertions (post-conditions and invariants stated explicitly); conceptual contours (code cut along the domain's natural seams, so change stays local); standalone classes (types understandable in isolation); closure of operations (operations that stay within one concept's type, composing without dragging in foreign types). Draw on these where they genuinely fit — they are inspiration, not a checklist.

At the same time exercise restraint: avoid interfaces nothing needs yet, and model only the abstractions the concept truly requires — a supple model stays small and concrete wherever the domain is concrete. Make only the changes the concept calls for. The quality of the resulting model is very important.

Think edge cases through deliberately — boundary values, missing data, failure paths — and let the tests state honestly what the model does in each of them. Treat tests as the model's documentation: every property your design claims, including its extension points, should be demonstrated by an executable test rather than described in a comment.