GRASP Principles

Look for method groups touching disjoint fields (the LCOM metric captures this), vague names, and files changed by many unrelated commits. Fix by extracting each concern into its own class, keeping the old class as a delegating facade until callers migrate.

Information Expert says 'put it where the data is', which keeps piling work onto data-rich classes. Cohesion is the veto: if the class stops having one clear purpose, move the responsibility to a new invented class — GRASP calls that Pure Fabrication.

Add it when you can name what it decouples: a real second implementation, an unstable external dependency, a test seam, or a place to put cross-cutting concerns. Otherwise you pay extra hops, harder debugging and more code for imagined flexibility.

Split the job. Each object computes the part it knows and asks its neighbour for the rest — a chain of "partial experts". An order asks each line item for its subtotal; each line item asks its product for the price.

Ordinary method calls pick an implementation from one object's type only. For two, you either chain two polymorphic calls (double dispatch, as in the Visitor pattern), or look the behavior up in a table keyed by the pair of types. Both trade simplicity for extensibility.

Polymorphism is the usual way to achieve Protected Variations (hide a varying thing behind a stable interface) and to get Open–Closed behavior (add a class, don't edit existing code). Liskov is the condition that makes it safe: every implementation must be usable wherever the interface is expected.

The interface probably wasn't stable: it exposed the provider's types, errors, or behaviour. If callers must know which implementation is behind the interface — for retries, error codes, ordering or quirks — the variation leaked and nothing was truly protected.

Pure Fabrication invents a non-domain class to keep cohesion high. Indirection puts a middleman between two things so they don't touch. Protected Variations hides something unstable behind a stable interface. They overlap often, but each can occur alone.

A good fabrication has one clearly named job, a stated reason it can't live on a domain class, few dependencies, and leaves entities holding their own rules. A god-service has a vague name, many unrelated methods, and reduces entities to data bags.

The same rule applies to services: whichever service owns the data should own the logic and decisions about it. If one service constantly fetches another's data to decide something, the responsibility is in the wrong place — move the behavior to the data owner instead of moving the data around.

Count incoming dependencies (afferent) and outgoing ones (efferent) per module, plus dependency-cycle checks. Accept higher coupling when the alternative is layers of indirection nobody needs — for stable, rarely-changing dependencies, or in small, short-lived, or performance-critical code.

Connascence means two pieces of code must change together to stay correct. It grades each dependency by strength (how hard it is to spot and fix), degree (how many places are involved) and locality (how far apart they are). Reduce strength, degree, or distance.

The controller is the one place every caller passes through, so transaction start/commit, permission checks, idempotency, and tracing spans fit there. Put them in the HTTP layer and non-HTTP callers skip them; put them in entities and they get duplicated and tangled.

Each module should own creation of its own types: outsiders send a request or data, and the owning module builds the object and checks the rules. Loading objects from a database is rebuilding an already-valid object, not creating a new one, so it may use a separate hidden path.

The same rule scales up: group things that change together into the same module or service. Grouping by technical layer instead of by business capability spreads every feature across many deployables, so one change needs many coordinated releases.

The idea is the same at every scale: put something in the middle so two sides don't couple. But once the middle is a separate process, you also inherit latency, partial failure, versioning, deployment and ownership — problems a method call never had.

It hurts when the variation isn't really by type, when several variation axes multiply into too many classes, when the variant list is duplicated in databases, APIs and configs, or when adding new operations means changing code owned by other teams. Then prefer data-driven rules, composition, or closed types with exhaustive checks.

At architecture scale, the wrapped variation is whole systems: vendors, external partners, legacy platforms, data formats. Protection means anti-corruption layers, ports and adapters, versioned contracts and plugin points — boundaries that also match who owns and deploys each side.

Each invented class adds a name to learn and a hop to follow. Overused, features spread across many thin files, entities go anemic, and reading code gets slow. Govern it with agreed roles, naming conventions, and an explicit reason for each new abstraction.