Good vs Poor Design

Coupling is the degree to which one module depends on another: how much it must know about the other's internals and how likely a change there forces a change here. Cohesion is the degree to which the elements inside one module belong together and serve a single purpose. Good design aims for low coupling between modules and high cohesion within them, because then each change lands in one place. A DiscountService that instantiates MySqlCustomerRepository and reads customer.orders directly is tightly coupled; a CustomerManager that registers customers, sends newsletters and exports Excel files has low cohesion. The two usually move together: splitting an incohesive class tends to reduce coupling as well.

Rigidity is the tendency of software to resist change: a simple modification forces a cascade of further changes in dependent modules, so the real size of any change is unpredictable. The cause is usually concrete dependencies everywhere and design decisions that are not hidden, such as a data format or currency representation known by dozens of classes. The visible symptom shows up in planning rather than in code: estimates like somewhere between three and twenty days, and managers reluctant to approve even small requests. The typical fixes are depending on abstractions, hiding volatile decisions behind one module, and narrowing wide interfaces so that fewer callers are affected by each change.

Rigidity means a change is large: you know you must edit many modules, so the work is slow but the impact is visible. Fragility means a change breaks things you did not touch and often did not know were related, so the cost appears later as regressions. Rigidity comes from explicit dependencies; fragility usually comes from hidden coupling, such as two classes sharing the meaning of a magic status code, global mutable state or duplicated rules with subtle differences. A rigid system stays red until every caller is fixed; a fragile one compiles green and fails in production. Fix fragility with explicit types, single definitions of rules and tests at boundaries.

Immobility is the inability to reuse a component in another context because separating it from its current surroundings costs more than rewriting it. The cause is entanglement: domain logic mixed with framework, transport and persistence code, or built on context-specific assumptions such as an HTTP request locale or a particular database schema. A tax calculation inside a Spring controller that uses EntityManager and HttpServletRequest cannot be called from a batch job, a test or another service. The usual result is copying the logic, which then creates duplication and drift. The cure is to extract pure domain logic with explicit inputs, such as a TaxCalculator taking Money, Region and LocalDate.

No. What matters is duplicated knowledge, not duplicated text. If the same business rule, such as free shipping over 50 euros, is written in checkout, UI and invoicing, every change must find all copies, and missed or slightly different copies become bugs, like > in one place and >= in another. But two pieces of code that look identical yet represent different rules, owned by different people and changing for different reasons, should stay separate; merging them creates coupling and an abstraction that bends under both sets of requirements. A good test is to ask whether a change to one would always require the same change to the other. If not, it is coincidence.

I combine static metrics with change history, because structure only costs money where code changes. Statically, I look at package dependency cycles with jdeps or ArchUnit, efferent and afferent coupling and instability per package, class cohesion such as LCOM4, cognitive complexity from SonarQube and duplicated blocks from PMD CPD, interpreted with care since each metric has blind spots. Then I add behavioural analysis from Git: hotspots, meaning files that are both complex and frequently changed, and change coupling, meaning files that always change together without an import relationship. Finally I check delivery data such as change failure rate and lead time per area. The output is a short, prioritised list.

Decay happens through many locally reasonable shortcuts, so the defence has to be continuous and mostly automatic. First, encode key structural rules as tests: no package cycles, correct layering and a domain independent of frameworks, using ArchUnit or Spring Modulith verification in CI so violations fail the build. Second, make refactoring part of every feature rather than a separate project, leaving touched code slightly better. Third, review boundaries and dependencies in design reviews and record significant decisions in ADRs. Fourth, track hotspots and change failure rate over time, so emerging problem areas are visible early. Finally, keep the test suite fast, because teams only refactor when they trust the safety net.

The same properties apply, but distribution multiplies their cost. Each service should be highly cohesive around one business capability and loosely coupled to others through stable APIs and events. The symptoms then appear at system scale: rigidity shows up as services that must be changed and deployed in lock-step, fragility as one service's failure or schema change cascading into incidents elsewhere, and immobility as capabilities that a new channel cannot reuse without dragging in another service's data. Duplicated business rules across services cause inconsistent behaviour between channels. Tight coupling between services also costs latency and availability, so drawing boundaries around cohesive capabilities is the architect's main lever.