Supple Design's 'standalone classes' principle pushes for minimizing a class's dependencies on other concrete types to reduce the mental overhead of understanding it in isolation. At what point does chasing standalone classes across a large domain model start working against you, and how do you recognize that trade-off point in practice?

## What standalone means **Standalone classes** means deliberately minimizing how many other concrete types a class depends on, so that understanding, testing, and modifying that one class doesn't require holding a large portion of the rest of the domain model in your head at the same time. Mechanically, this means: - favoring dependencies on primitives and a small number of other already-standalone value types, such as numbers, strings, dates, and things like a `Money` or `DateRange` that are themselves standalone, over dependencies on large entities, services, or repositories; - auditing a class's constructor and method parameters and fields for concrete types that could be removed, narrowed to an interface, or replaced with a value that doesn't require the whole surrounding object graph. ## Why it pays off The motivation is cognitive load and testability. A class with zero or few dependencies can be constructed and exercised in a unit test with no mocks, no fixtures, and no setup beyond the values it directly needs -- you read its interface, build one, and reason about its behavior completely in isolation. This pays off disproportionately for value objects and small computational building blocks, like `Money`, `DateRange`, and `Percentage`, that get reused throughout a codebase: every place that uses them benefits from the same low-friction understanding, and changes to them are easy to verify don't ripple outward because there's little for them to ripple through in the first place. ## The trade-off The trade-off is that not every domain concept is standalone by nature -- some are genuinely relational, meaning their behavior is only meaningful in terms of other concrete types. An `Order` legitimately needs to know about its `LineItems` and its `Customer`; a `LoanApplication` legitimately needs an applicant, a requested amount, and an underwriter to do anything useful. Applying 'minimize dependencies' as an absolute, context-free rule to a genuinely relational entity doesn't remove the coupling those relationships represent, it just relocates it. If a class's dependency is stripped out and replaced with loosely-typed primitives, such as an ID string instead of a typed reference, or three separate booleans instead of a status enum from another type, the information the class needs is still required at every call site, just now without the type safety and self-documentation the original dependency provided. ## How over-application fails - In practice, the failure shows up as a class whose method signature grows longer and more primitive-obsessed after a well-intentioned decoupling pass -- `validate(Customer customer)` becomes `validate(String customerId, boolean isCustomerActive, String customerCountryCode)` -- and now every caller has to independently look up and correctly assemble those three values, duplicating logic that used to live in one place, wherever that `Customer` object was obtained, and losing the guarantee that 'an active customer in Germany' is a coherent, validated concept rather than three coincidentally-consistent primitives. - Another failure mode is over-applying reference-by-ID as a decoupling technique across an entire domain model: every entity refers to its collaborators only by ID, which does reduce compile-time coupling, but every consumer that actually needs the related data now has to perform its own lookup or join, often duplicating that lookup logic across many call sites -- the indirection layer's own complexity can end up exceeding the coupling it removed. ## A good candidate and a poor one - A `DateRange` class holding a start date, end date, and methods like `overlaps(DateRange)` and `durationInDays()` is a strong standalone candidate: it's fully self-contained, trivially testable, and reusable anywhere date-range logic is needed, from a loan's grace period to a hotel booking's stay length, with no changes to `DateRange` itself. - Contrast that with a `LoanApplication`, which needs an applicant, a requested amount, a credit-check result, and an assigned underwriter to make any decision at all; trying to force it toward 'standalone' by replacing those with raw identifiers just means every piece of code operating on a `LoanApplication` has to separately fetch and correctly interpret applicant and underwriter data, reproducing the same coupling without the compiler's help. The practical judgment call -- recognizing `DateRange` as a good standalone candidate and `LoanApplication` as a poor one -- is what separates using this principle well from applying it as blind dogma across an entire model.