DEV Community: Yannick Loth

On the Nature of Cohesion

Yannick Loth — Mon, 01 Jun 2026 15:29:03 +0000

I've published a new paper: On the Nature of Cohesion: Cohesion as a Two-Axis Schema.

Cohesion is one of the oldest concepts in software design — introduced by Stevens, Myers, and Constantine in 1974, taught in every curriculum, invoked in every code review. For fifty years, the field has struggled to define it formally. Every published definition is a characterization, not an operational criterion. Every published metric measures a structural proxy.

The paper surveys the major cohesion metrics from the literature, formalizes what cohesion is under any admissible modularization principle, develops the necessary conditions a principled cohesion metric must satisfy, and diagnoses why existing approaches fall short.

If you teach cohesion, apply it in code reviews, or work on software metrics — this paper directly concerns the concept you're using.

Yannick Loth. On the Nature of Cohesion: Cohesion as a Two-Axis Schema. June 2026.

DOI: 10.5281/zenodo.20492913 — free on Zenodo.

SRP's Vocabulary Problem: Why Every Reformulation Failed

Yannick Loth — Fri, 29 May 2026 13:24:13 +0000

I've just published SRP's Vocabulary Problem: Why Every Reformulation Failed.

The Single Responsibility Principle has been criticized as vague, ambiguous, and arbitrary for thirty years. A companion paper shows it carries a demonstrable cardinality error — but that error was hiding in plain sight. Why did no one see it?

This paper answers that question. The vocabulary SRP inherited — "concern" from Dijkstra, "responsibility" from Martin — imports a cardinality assumption before any reasoning begins. The words make the right question unaskable.

📄 Read the paper: 10.5281/zenodo.20445691

📄 Companion paper: SRP Is Wrong: The Cardinality Error in the Single Responsibility Principle

SRP Is Wrong: The Cardinality Error in the Single Responsibility Principle

Yannick Loth — Wed, 27 May 2026 16:52:24 +0000

I've published a new paper: Why SRP Is Wrong: The Cardinality Error in the Single Responsibility Principle.

SRP — "a class should have only one reason to change" — is wrong. Not vague or misunderstood. Wrong.

The adapter pattern is a counterexample. A Stripe payment adapter has two reasons to change: the internal PaymentProcessor interface changes, or Stripe's API changes. Under Martin's own interpretation of his terms, that's two — not one.

SRP's prescribed remedy is to split the module. But splitting an adapter destroys its function — mediation requires both domains' knowledge in the same reasoning step. Three salvage attempts (DTO intermediate, mapping table, delegation) all fail. The adapter is irreducibly composite.

The class of counterexamples is not marginal. Every façade, bridge, API gateway, protocol translator, and anti-corruption layer that mediates between independent domains is equally a counterexample. Most complex systems contain them.

The paper formalizes the refutation in the change-driver apparatus with complete theorems and proofs. The formal apparatus is not needed to follow the argument — the counterexample stands alone — but is provided for readers who want the argument in precise, verifiable form.

Paper: Why SRP Is Wrong: The Cardinality Error in the Single Responsibility Principle., May 2026.

If you teach SRP or apply it in code reviews: does this refutation change how you think about the principle?

SOLID Heuristics Reveal Incomplete Domain Knowledge — Nothing More

Yannick Loth — Sun, 24 May 2026 21:39:02 +0000

SOLID — Single Responsibility, Open/Closed, Liskov Substitution, Interface Segregation, Dependency Inversion — has been taught for three decades as five independent design principles [Martin 1996a, 1996b, 2000, 2003]. Every software engineer learns them. Every code review invokes them.

This article argues that each SOLID heuristic is not a design principle in the formal sense. It is a diagnostic pattern for a specific way domain knowledge is incomplete or incorrectly expressed. The heuristics exist only because we do not, in practice, document causal domain knowledge completely. Were we to do so, the correct design follows automatically — no heuristic check required.

How each case is presented

For each heuristic that addresses change management (SRP, OCP, ISP, DIP), the analysis follows a three-step method:

Knowledge with the gap. A domain statement as it is typically written — incomplete or compound — producing flawed code. The SOLID heuristic correctly flags this code. But the heuristic identifies the symptom, not the cause.
Knowledge without the gap. The same domain knowledge expressed correctly — decomposed into irreducible sub-statements, each governed by a distinct change driver. This is the knowledge correction. It is not a code refactoring; it is an epistemic act: recognizing what can independently cause each element to change.
IVP application. The corrected knowledge yields driver assignments Γ. IVP-2 decomposes reducible composites. IVP-3 and IVP-4 produce the unique module partition. The structure the heuristic prescribed emerges automatically. The heuristic itself was never invoked — it was only needed because the knowledge had a gap.

LSP is treated separately: it is a hybrid. IVP still determines which types share a driver and therefore belong in the same module. When the structural placement is wrong — types with different invariants forced into a hierarchy — correcting Γ resolves the violation like the others. When the structural placement is correct but the behavioral contract is broken, Bertrand Meyer's Design by Contract — a type-theoretic discipline — takes over.

The argument rests on the Independent Variation Principle (IVP), a formal theory of software modularization. I state it first.

The Independent Variation Principle

IVP defines a software system as a six-tuple S = (F, κ_F, E, K, C, Γ) where:

F is the set of functional purposes the system must fulfill
κ_F is the causal domain knowledge the system must embody to fulfill F
E is the set of software elements — classes, functions, modules
K is the universe of all possible domain knowledge
C is the set of change drivers — forces that can causally require elements to be modified (regulations, contracts, interface specifications, stakeholder commitments, hardware evolution)
Γ : E → P(C) is the driver assignment function, mapping each element to the set of change drivers that can cause it to require modification

The driver assignment Γ is the central object. Γ(e) answers one question: what can cause this element to change? The answer is not a design preference — it is a fact about the system's causal reality. Two engineers who correctly analyze the same system must arrive at the same Γ. If they disagree, at least one analysis is incomplete.

The four IVP directives are:

IVP-1 — Element Admissibility. Every element must have at least one change driver: |Γ(e)| ≥ 1 for all e ∈ E. An element with no driver serves no purpose and should be removed.

IVP-2 — Change Driver Assignment. Every element is either pure (|Γ(e)| = 1) or irreducibly composite (|Γ(e)| > 1 with no decomposition possible without losing function). A reducible composite — an element that could be split to reduce its driver set — is a design defect. A reducible element is evidence that domain knowledge was over-specified, conflated, or incompletely analyzed.

IVP-3 — Unit Purity (Separation). Elements with different driver assignments must not occupy the same module: ∀ M ∈ M, ∀ e, e' ∈ M : Γ(e) = Γ(e').

IVP-4 — Unit Completeness (Unification). Elements with the same driver assignment must occupy the same module: ∀ e, e' : Γ(e) = Γ(e') ⇒ ∃ M ∈ M : {e, e'} ⊆ M.

IVP-3 and IVP-4 together form a biconditional: two elements belong in the same module if and only if they share the same driver assignment. The modularization is precisely the partition of E induced by e₁ ∼ e₂ ⇔ Γ(e₁) = Γ(e₂).

Four directives. No heuristics. No weighing of trade-offs. The answer falls out of Γ.

SRP: Bundled Causal Concerns

Knowledge with the gap

Domain statement: "The system calculates employee pay, formats pay statements, and emails them to employees."

This is a compound statement bundling three independent concerns. The resulting code:

class PayCalculator {
    BigDecimal calculatePay(Employee e) { /* tax rules, benefits, overtime */ }
    String formatPayStatement(Employee e) { /* PDF layout, company logo, line items */ }
    void emailPayStatement(Employee e, String statement) { /* SMTP config, attachments */ }
}

SRP says: "A class should have only one reason to change" [Martin 2003]. PayCalculator has three: tax rules change, statement layout changes, email infrastructure changes. SRP flags this — correctly — as a defect.

But SRP does not tell you why the defect exists.

Knowledge without the gap

Domain statement (corrected):

"Pay calculation is governed by tax regulations and benefits contracts."

"Pay statement formatting is governed by document layout standards."

"Pay statement delivery is governed by the organization's mail infrastructure."

Three irreducible statements, each governed by a distinct authority. The correction is not a code refactoring — it is a knowledge revision: the compound statement has been decomposed.

IVP application

From the corrected knowledge, the driver assignments follow directly:

Element	Γ (change drivers)
`TaxCalculator`	{γ_tax}
`PayStatementFormatter`	{γ_format}
`PayStatementMailer`	{γ_email}

Each element is pure: |Γ(e)| = 1. IVP-2 is satisfied.

The driver sets differ ({γ_tax} ≠ {γ_format} ≠ {γ_email}). IVP-3 places each element in its own module:

Payroll module: TaxCalculator (driven by γ_tax)
Formatting module: PayStatementFormatter (driven by γ_format)
Delivery module: PayStatementMailer (driven by γ_email)

SRP was never invoked. The decomposition falls out of Γ. The resulting class structure — three separate classes, each with a single driver — is identical to what SRP would prescribe. But SRP needed a heuristic check to get there. IVP needed only correct Γ.

Accidental coupling: with the gap vs. without

With the gap, the compound knowledge statement creates accidental coupling between three independent driver domains. TaxCalculator's pay calculation logic is coupled to the formatting code and the email delivery code — not because they share causal drivers, but because the knowledge bundled them into one statement. A change to statement layout (γ_format) touches tax calculation code in the diff. A change to email infrastructure (γ_email) forces recompilation of the pay calculation module. These are accidental dependencies: PayCalculator depends on formatting and email delivery code, but not because the domain requires it.

Without the gap, there is no accidental coupling. Each module contains elements governed by exactly one driver. A dependency exists only where the domain demands it: PayStatementMailer depends on TaxCalculator because the delivery module genuinely needs pay data to construct the email. That is an intentional, domain-justified dependency. The coupling that remains is of the form dependency — one module depends on another. All the coupling discussed in this example is dependency coupling; other forms of coupling exist (data coupling, temporal coupling, coupling via shared state) but do not arise here.

When SRP is wrong

SRP says "a class should have only one reason to change" — it demands |Γ(e)| = 1 for every element. But some elements are irreducibly composite: they genuinely embody knowledge from multiple drivers and cannot be split without losing function. SRP would demand splitting them anyway. That is not a knowledge correction — it is a design error.

An adapter between a payment system (γ_payment) and a foreign exchange service (γ_fx) genuinely needs to know both domains: payment message formats and currency conversion protocols. The domain knowledge is not reducible:

Domain statement: "A payment-to-FX adapter translates payment instructions into currency exchange requests."

This is one statement — not a compound of two independent ones — because the translation is the element's function. Splitting it into two elements would leave each unable to perform the translation. Γ(adapter) = {γ_payment, γ_fx} is irreducible. IVP-2 permits this. SRP does not.

SRP is not just unnecessary when knowledge is complete — it is wrong for systems that contain legitimate multi-driver elements. IVP-2's irreducibility test distinguishes the two cases: reducible (PayCalculator — defect, must split) from irreducible (payment-to-FX adapter — legitimate, must not split). SRP makes no such distinction.

The knowledge flaw SRP detects (when correct): Domain knowledge expressed as a compound statement rather than as irreducible sub-statements. SRP is the diagnostic for the reducible case; Γ and the irreducibility test handle both cases correctly.

OCP: Failure to Anticipate Driver-Independent Variation

Knowledge with the gap

Domain statement: "The system sends notifications by email."

This statement embeds the notification channel into the notification act. The resulting code:

class NotificationService {
    void notify(String message) {
        emailSender.send(message);  // hard-coded to email
    }
}

OCP says: "Software entities should be open for extension but closed for modification" [Meyer 1988]. Adding SMS requires modifying NotificationService — a violation.

But OCP does not tell you what knowledge is missing.

Knowledge without the gap

Domain statement (corrected):

"The system sends notifications."

"Email delivery is governed by the SendGrid API and email template standards."

"SMS delivery is governed by the Twilio API."

"Push notification delivery is governed by Firebase Cloud Messaging."

Each channel is governed by its own change driver: the email infrastructure (γ_email), the SMS provider (γ_sms), and the push notification service (γ_push). The notification act itself is governed by the notification-content driver (γ_notification). Adding a new channel — say, WhatsApp — means adding a new driver (γ_whatsapp) without modifying existing code.

IVP application

Element	Γ (change drivers)
`NotificationService`	{γ_notification}
`NotificationChannel` (interface)	{γ_notification}
`EmailChannel`	{γ_notification, γ_email}
`SmsChannel`	{γ_notification, γ_sms}
`PushChannel`	{γ_notification, γ_push}

NotificationService and NotificationChannel share {γ_notification} — IVP-4 unifies them in the same module.

Each channel implementation is an irreducible composite: it must know the notification contract (γ_notification — the interface it realizes) and its own delivery mechanism (γ_email, γ_sms, or γ_push). Splitting either driver out would destroy the element's function — it could not send notifications without knowing the contract, and could not deliver without knowing the infrastructure. IVP-2 permits this: the composite is irreducible.

The driver sets differ: {γ_notification} ≠ {γ_notification, γ_email} ≠ {γ_notification, γ_sms} ≠ {γ_notification, γ_push}. IVP-3 places each in its own module:

Notification module: NotificationService, NotificationChannel
Email module: EmailChannel
SMS module: SmsChannel
Push module: PushChannel

OCP was never invoked. The resulting structure — an abstraction (NotificationChannel) with separate channel implementations, each in its own module — is identical to what OCP would prescribe. But OCP needed a heuristic check to get there. IVP needed only correct Γ.

The same design also satisfies ISP and DIP. ISP: each channel depends only on the NotificationChannel contract it uses — no channel is forced to depend on other channels' delivery methods. DIP: NotificationService depends on the NotificationChannel abstraction, not on concrete channels; the interface is owned by the notification domain (high-level), not by the channel implementations (low-level). The three heuristics converge on the same structure because they all address the same underlying reality: variation forces are independent, and dependencies must honor that independence.

Accidental coupling: with the gap vs. without

With the gap, the knowledge statement "the system sends notifications by email" creates accidental coupling between the notification dispatch logic and the email delivery infrastructure. NotificationService is coupled to EmailSender — not because the domain requires dispatch logic to know about email delivery, but because the knowledge embedded the channel into the notification act. A change to SMS delivery (γ_sms) touches NotificationService in the diff. The coupling is accidental: NotificationService depends on email delivery code, but the domain only requires it to depend on the abstract notion of sending a notification.

Without the gap, there is no accidental coupling. NotificationService depends only on NotificationChannel — an abstraction governed by its own driver (γ_notification). Each channel module carries an intentional, irreducible dependency on both γ_notification (the contract it implements) and its infrastructure driver. The coupling that remains is of the form dependency — the service depends on the abstraction, each channel depends on the abstraction. Again, all the coupling visible here is dependency coupling. Adding WhatsApp adds a new module governed by γ_whatsapp. No existing module is modified. OCP says "open for extension, closed for modification." Γ makes the statement structural: a new driver means a new module. Existing modules are closed.

The knowledge flaw OCP detects: Knowledge that treats variation points as fixed, when the domain contains forces — each channel's governing infrastructure — that will activate independently. OCP is the diagnostic; recognizing each variation force as a distinct change driver resolves it.

LSP: Structural Placement First, Behavioral Validity Second

LSP is different from the other four, but not as different as it first appears. The other four are purely knowledge diagnostics: the knowledge is wrong, correct it, the design follows. LSP is a hybrid. IVP still decides where types live — and the LSP violation often reveals that the structural placement was wrong.

Knowledge with the gap

Domain statement: "The system models geometric shapes. Rectangle and Square are shapes with width and height."

This statement treats Rectangle and Square as sharing the same driver — geometry. But they don't. A Rectangle has two independent dimensions. A Square has one dimension with the constraint that width equals height. They are governed by different invariants.

The resulting code:

class Rectangle {
    void setWidth(int w) { this.width = w; }
    void setHeight(int h) { this.height = h; }
}
class Square extends Rectangle {
    @Override
    void setWidth(int w) { this.width = w; this.height = w; } // breaks invariant
    @Override
    void setHeight(int h) { this.width = h; this.height = h; }
}

LSP says: "Subtypes must be substitutable for their base types" [Liskov 1987, Liskov and Wing 1994]. Square is not — a method accepting Rectangle that calls setWidth(5); setHeight(10) gets a 10×10 square instead of a 5×10 rectangle. But the heuristic only flags the behavioral violation. It does not tell you why the violation exists.

Knowledge without the gap

Domain statement (corrected):

"A rectangle is a shape with independent width and height."

"A square is a shape with a single side length."

These are two distinct knowledge statements. The invariant "width = height" is a domain fact about squares, not a property derivable from rectangles. Treating Square as a subtype of a mutable Rectangle is the knowledge error — the domain knowledge was incorrectly modeled as an inheritance relationship rather than as two separate shape types.

IVP application

Element	Γ (change drivers)
`Rectangle`	{γ_rect}
`Square`	{γ_square}

The drivers differ: {γ_rect} ≠ {γ_square}. IVP-3 places them in separate modules — no inheritance hierarchy connecting them. Each type governs its own invariant. The LSP violation was a symptom of a structural misplacement: two types with different drivers were forced into a subtype relationship.

class Rectangle {
    void setWidth(int w) { this.width = w; }
    void setHeight(int h) { this.height = h; }
}
class Square {
    void setSide(int s) { this.side = s; }
    // No inheritance. No shared invariant to break.
}

When LSP is not a knowledge gap

LSP can also surface purely behavioral problems even when IVP placement is correct. Two elements genuinely share a driver and IVP-3/4 place them together in the same module. Inheritance is the chosen mechanism for sharing behavior. But the subtype breaks the behavioral contract — it strengthens preconditions or weakens postconditions relative to the base type. Here the driver assignments are correct; the defect is in the contract design, not in Γ. This is where Bertrand Meyer's Design by Contract — a type-theoretic discipline — takes over from IVP.

LSP is a hybrid. When the structural placement is wrong — types with different invariants forced into a hierarchy — correcting Γ resolves the violation. The resulting class structure — two independent types, no inheritance — is what the corrected knowledge demands. LSP would have flagged the behavioral violation but could not diagnose the structural cause. IVP provides the structural diagnosis; when that suffices, the behavioral violation disappears because the hierarchy no longer exists.

Accidental coupling: with the gap vs. without

With the gap, the knowledge statement treats Rectangle and Square as sharing a driver. The subtype relationship creates accidental coupling: Square is coupled to Rectangle's invariant that width and height are independent — not because the domain requires squares to have two independent dimensions, but because the knowledge modeled Square as a special case of Rectangle. A change to Rectangle's invariant (γ_rect) forces re-verification of every Square in the system. Any client code that passes a Square where a Rectangle is expected may silently produce wrong results. The coupling is accidental: Square inherits from Rectangle, but the domain says Square has one dimension, not two.

Without the gap, there is no accidental coupling. Rectangle and Square are separate types in separate modules, each governed by its own driver. γ_rect activates → only Rectangle changes. Square is untouched. No invariant re-verification across types. No substitution surprise. Each type governs its own change space. The only coupling between them — if any — would be an intentional dependency in code that genuinely uses both, not a forced subtype relationship. The coupling that was eliminated is behavioral (substitution via inheritance); the coupling that would remain, if any, is of the form dependency. Coupling is not a single thing.

ISP: Conflated Client Contracts

Knowledge with the gap

Domain statement: "The system has a reporting interface that serves accounting, analytics, and management reporting needs."

This statement bundles three distinct client contracts into one. The resulting code:

interface ReportService {
    Report generatePdf(FinancialData data);     // accounting
    Report generateCsv(MetricsData data);        // analytics
    Report generateExcel(DashboardData data);    // management
}
class AccountingClient {
    ReportService service;  // forced to depend on generateCsv, generateExcel
    void run() { service.generatePdf(ledgerData); }
}

ISP says: "Many client-specific interfaces are better than one general-purpose interface" [Martin 1996b]. AccountingClient depends on methods it never uses — a violation.

But ISP does not tell you why the violation exists.

Knowledge without the gap

Domain statement (corrected):

"Accounting requires PDF reports of financial data."

"Analytics requires CSV exports of operational metrics."

"Management requires Excel dashboards of KPIs."

Each client's contract is a distinct knowledge slice, governed by its own change driver — accounting regulations, analytics requirements, and management reporting standards, respectively.

IVP application

Element	Γ (change drivers)
`AccountingClient`	{γ_accounting}
`AccountingReport` (interface)	{γ_accounting}
`AnalyticsClient`	{γ_analytics}
`AnalyticsReport` (interface)	{γ_analytics}
`ManagementClient`	{γ_management}
`ManagementReport` (interface)	{γ_management}

Each interface shares its client's Γ. IVP-4 unifies each client-interface pair. {γ_accounting} ≠ {γ_analytics} ≠ {γ_management}, so IVP-3 separates them:

Accounting module: AccountingClient, AccountingReport
Analytics module: AnalyticsClient, AnalyticsReport
Management module: ManagementClient, ManagementReport

ISP was never invoked. The resulting structure — each client with its own interface, no shared general-purpose interface — is identical to what ISP would prescribe. But ISP needed a heuristic check to get there. IVP needed only correct Γ. No client depends on methods it does not use, because no interface contains methods governed by another client's driver.

Accidental coupling: with the gap vs. without

With the gap, the knowledge statement "the system has a reporting interface serving accounting, analytics, and management" creates accidental coupling between three independent client domains. AccountingClient is coupled to generateCsv and generateExcel — not because accounting requires CSV exports or Excel dashboards, but because the knowledge bundled all three contracts into one interface. A change to analytics requirements (γ_analytics) — adding a new CSV field — forces recompilation of AccountingClient, even though accounting's driver is unchanged. The dependency is accidental: AccountingClient depends on methods it does not use, forced by a shared interface that couples three independent driver domains.

Without the gap, there is no accidental coupling. Each client depends only on its own interface — an abstraction governed by the same driver. γ_analytics activates → only the Analytics module (AnalyticsClient, AnalyticsReport) changes. AccountingClient is not in the diff, not recompiled, not re-verified. The coupling that remains is of the form dependency — each client depends on its own interface, which is governed by the same driver. All the coupling discussed here is dependency coupling. ISP says "no client should depend on methods it doesn't use." Γ makes that structural: no module depends on code governed by another module's driver.

The knowledge flaw ISP detects: Conflated client contracts — domain knowledge that bundles what should be separate slices, each governed by a distinct client's change driver. ISP is the diagnostic; identifying each client's driver resolves it.

DIP: Bundled Abstraction and Implementation

Knowledge with the gap

Domain statement: "OrderProcessor persists orders to MySQL."

This statement compounds an abstract capability (persist orders) with a specific realization (MySQL). The resulting code:

class OrderProcessor {
    private MySQLOrderRepository repository;  // concrete dependency
    void process(Order order) {
        // ... business rules ...
        repository.save(order);
    }
}

DIP says: "Depend on abstractions, not on concretions" [Martin 1996a]. OrderProcessor directly depends on a concrete database technology — a violation.

But DIP does not tell you what knowledge is incorrectly expressed.

Knowledge without the gap

Domain statement (corrected):

"Order processing applies business rules to orders and persists the result."

"Persistence technology — MySQL, PostgreSQL, in-memory — varies independently of order business rules."

The correction separates abstract capability from implementation technology. The persistence mechanism is recognized as an independent change driver (γ_persistence) whose activation — switching databases — should not modify OrderProcessor.

IVP application

Element	Γ (change drivers)
`OrderProcessor`	{γ_order}
`OrderRepository` (interface)	{γ_order}
`MySqlOrderRepository`	{γ_persistence}
`PostgreSqlOrderRepository`	{γ_persistence}

The interface OrderRepository shares {γ_order} with OrderProcessor — IVP-4 unifies them. The implementations share {γ_persistence} — IVP-4 places them together. {γ_order} ≠ {γ_persistence}, so IVP-3 separates the two modules:

Order module: OrderProcessor, OrderRepository
Persistence module: MySqlOrderRepository, PostgreSqlOrderRepository

DIP was never invoked. The resulting structure — an abstraction owned by the high-level module, with implementations in a separate module — is identical to what DIP would prescribe. But DIP needed a heuristic check to get there. IVP needed only correct Γ. OrderProcessor depends on an interface governed by its own driver — exactly the dependency structure DIP prescribes, derived from Γ alone.

Accidental coupling: with the gap vs. without

With the gap, the knowledge statement "OrderProcessor persists orders to MySQL" creates accidental coupling between order processing and persistence technology. OrderProcessor is coupled to MySQLOrderRepository — not because order business rules require MySQL, but because the knowledge bundled the abstraction with a specific implementation. A change to persistence technology (γ_persistence) — switching to PostgreSQL — forces modification of OrderProcessor, even though order business rules are unchanged. The concrete dependency couples two independent driver domains. The coupling is accidental: OrderProcessor depends on MySQL, but the domain only requires it to depend on the abstract capability of persisting orders.

Without the gap, there is no accidental coupling. OrderProcessor depends only on OrderRepository — an abstraction governed by its own driver (γ_order). γ_persistence activates → only the Persistence module (MySqlOrderRepository, PostgreSqlOrderRepository) changes. The Order module is not in the diff — the interface OrderRepository insulates it. γ_order activates → only the Order module changes. The coupling that remains is of the form dependency — OrderProcessor depends on the interface, implementations depend on the interface. Again, all the coupling discussed here is dependency coupling. The abstraction (OrderRepository) is the structural seam where IVP-3 separates the two driver domains, and the interface ownership — with the order module, not the persistence module — ensures that changes to persistence technology cannot force changes to order processing.

The knowledge flaw DIP detects: Bundled abstraction and implementation — domain knowledge that compounds an abstract capability with a specific realization, when the two are governed by independent change drivers. DIP is the diagnostic; recognizing the implementation technology as an independent driver resolves it.

The Synthesis

Heuristic	Knowledge with the gap	Knowledge without the gap	Γ after correction	IVP resolution
SRP	"The system calculates pay, formats statements, and emails them"	Three separate statements, each with its own governing authority	Three pure elements, each {γ_i}	IVP-2 decomposes reducible composites; IVP-3 separates. Wrong in general: SRP also demands splitting irreducible composites (adapters) that IVP-2 correctly permits.
OCP	"The system sends notifications by email"	"Notification is governed by notification requirements. Each channel — email, SMS, push — has its own governing infrastructure."	{γ_notification} for service and interface; {γ_notification, γ_email}, {γ_notification, γ_sms}, {γ_notification, γ_push} for channels (irreducible composites)	IVP-3 separates per channel; IVP-2 permits the irreducible composite; IVP-4 unifies service with its interface
LSP	"Rectangle and Square are shapes with width and height"	"Rectangle has independent width and height. Square has a single side length with the constraint width = height."	{γ_rect} for Rectangle, {γ_square} for Square	IVP-3 separates; the subtype relationship was forced onto two types with different invariants. Hybrid: when Γ is correct but contract is broken, Bertrand Meyer's Design by Contract is needed.
ISP	"The system has a reporting interface serving accounting, analytics, and management"	Three separate client contracts, each governed by its own driver	Interface-client pairs share Γ	IVP-4 unifies each pair; IVP-3 separates across clients
DIP	"OrderProcessor persists orders to MySQL"	"Order processing and persistence technology vary independently"	{γ_order} for processor and interface, {γ_persistence} for implementations	IVP-3 separates abstraction from implementation

The pattern is uniform for SRP, OCP, ISP, and DIP. Each identifies a particular way domain knowledge is incomplete or incorrectly expressed. The prescription is always the same: decompose the compound or incomplete knowledge statement into irreducible sub-statements with distinct driver assignments; let the code structure emerge from correct Γ.

SRP is additionally wrong in general: it demands purity (|Γ(e)| = 1) for every element, failing to recognize legitimate irreducible composites such as adapters, facades, and protocol translators. IVP-2's irreducibility test is the correct criterion — it decomposes the reducible (PayCalculator) and permits the irreducible (payment-to-FX adapter). SRP lacks this distinction.

LSP is a hybrid. When the structural placement is wrong — types with different invariants forced into a hierarchy — the violation resolves like the others: correct Γ, IVP separates, the problem disappears. When the structural placement is correct but the behavioral contract is broken, Bertrand Meyer's Design by Contract is needed. The other four heuristics are purely knowledge diagnostics; LSP spans both domains.

What This Means

Were domain knowledge always causally complete and correctly documented, the four IVP directives would produce the correct design automatically. Γ would capture every element's causal dependencies. IVP-2 would flag every reducible composite. IVP-3 and IVP-4 would produce the unique module partition. There would be nothing for SRP, OCP, ISP, or DIP to do.

The heuristics exist only because, in practice, domain knowledge is incomplete or incorrectly expressed. When a designer applies SRP to a class with multiple reasons to change, they are correcting a knowledge defect — the statement "the system calculates pay, formats statements, and emails them" should be three statements. When a designer applies DIP to a concrete dependency, they are correcting a knowledge defect — the statement "OrderProcessor persists to MySQL" bundled abstract capability with implementation detail.

SOLID heuristics are reports of incomplete knowledge. They do not produce correct structure from correct inputs — they diagnose incorrect inputs. IVP is the general law that would be sufficient if knowledge were complete.

The fact that the IVP-derived structures are identical to what each heuristic prescribes — same class decomposition, same abstraction boundaries, same interface segregation — is not a coincidence. Three independent discovery paths converge on the same structural conclusions: mathematical derivation from cost axioms, empirical debugging experience encoded in SOLID, and epistemic insight that software design is knowledge work. When a heuristic's prescription matches what IVP derives from correct Γ, the heuristic identifies a genuine structural condition; IVP explains why that condition holds. When a heuristic diverges — SRP demanding splits of irreducible composites — IVP identifies the error and supplies the correct criterion.

This framing has practical consequences. A designer who understands IVP has no need for SRP, OCP, ISP, or DIP as separate rules. IVP provides a strictly stronger and more precise criterion — one that avoids the errors those heuristics introduce outside their narrow conditions. SRP demands splitting legitimate multi-driver modules (irreducible composites). OCP and ISP are silent about unification (IVP-4). IVP's four directives cover both separation and unification, pure and composite elements, with formal precision.

The question to ask when a SOLID heuristic appears to apply is not "how do I fix this code?" but "what causal domain knowledge is missing or incorrectly expressed such that this code structure emerged?" The code defect is a symptom. The knowledge defect is the cause.

A note on Robert C. Martin's achievement

This article argues that SOLID heuristics are diagnostic patterns for incomplete knowledge, not design principles. That does not diminish Robert C. Martin's contribution. Identifying five recurrent patterns across decades of practitioner experience — and giving them names that the entire industry adopted — is a remarkable feat of pattern recognition [Martin 1996a, 1996b, 2000, 2003]. The heuristics are not principles in the formal sense, but their identification was an act of genuine discovery.

Several authors have previously observed that SOLID's five heuristics are not all independent. Henney [2016] argued that ISP becomes redundant if SRP is properly applied. Oldwood [2014] proposed that all five reduce to two concepts. Kaminski [2019] noted that SRP, ISP, and DIP rehash similar concepts around managing dependencies. Terhorst-North [2022] proposed replacing SOLID entirely with a different framework. None of these critiques identified the specific mechanism that IVP reveals: each heuristic is a diagnostic pattern for a particular way domain knowledge is incomplete or incorrectly expressed.

This interpretation is itself only possible because of a formal theoretical development of the matter. The Independent Variation Principle provides a fundamental, principled design practice — four directives derived from the Change Management Hypothesis — that determines a unique module partition from causal domain knowledge alone. Without this formal foundation, SOLID's heuristics remain disconnected rules of thumb. Earlier critics could sense overlap and redundancy. They could not specify why each heuristic arises or what structural situation it addresses — because those answers require the apparatus of change drivers, driver assignments, and the IVP directives. IVP does not merely critique SOLID. It provides the formal framework within which SOLID's contribution — and its limits — become legible.

Three of the five — OCP, ISP, and DIP — have been essential in module boundary design for roughly thirty years. They address what happens at the seam between modules: OCP says don't modify existing code, extend through a boundary. ISP says segregate interfaces per client at the boundary. DIP says depend on abstractions owned by the high-level module, not on concretions from the low-level one. These three are the practical workhorses of boundary design. They converge on the same structural truth IVP formalizes: variation forces are independent, and module boundaries must honor that independence.

SRP is different. It addresses internal cohesion — what belongs inside a class — not boundary structure. Its prescription ("one reason to change") is correct for reducible composites but wrong for irreducible ones. LSP is also different: it addresses behavioral contracts within a type hierarchy, not boundaries between modules. The three boundary heuristics are where SOLID's lasting value lies. The other two diagnose real problems but lack the generality of the boundary principles — and the formal foundation that IVP provides.

References

[Henney 2016] Kevlin Henney. SOLID Deconstruction. NDC London, January 2016.
[Kaminski 2019] Tomasz Kamiński. Deconstructing SOLID design principles. Blog post, April 2019.
[Liskov 1987] Barbara Liskov. Data Abstraction and Hierarchy. OOPSLA 1987, Addendum to the Proceedings.
[Liskov and Wing 1994] Barbara Liskov and Jeannette M. Wing. A Behavioral Notion of Subtyping. ACM Transactions on Programming Languages and Systems, 16(6):1811–1841, 1994.
[Martin 1996a] Robert C. Martin. The Dependency Inversion Principle. C++ Report, May 1996.
[Martin 1996b] Robert C. Martin. The Interface Segregation Principle. C++ Report, August 1996.
[Martin 2000] Robert C. Martin. Design Principles and Design Patterns. Object Mentor, 2000.
[Martin 2003] Robert C. Martin. Agile Software Development: Principles, Patterns, and Practices. Prentice Hall, 2003.
[Meyer 1988] Bertrand Meyer. Object-Oriented Software Construction. Prentice Hall, 1988.
[Oldwood 2014] Chris Oldwood. KISSing SOLID Goodbye. ACCU Overload, 22(122), August 2014.
[Terhorst-North 2022] Daniel Terhorst-North. CUPID — for joyful coding. Blog post, 2022.

Where Do Interfaces Live? IVP Answers What SOLID Cannot

Yannick Loth — Sat, 18 Apr 2026 10:23:51 +0000

If you know a software architect, a professor who teaches SOLID, or anyone who takes design principles seriously — I'd appreciate you sharing this with them.

Two companion papers established the structural biconditional between ISP and per-client DIP (paper 1) and proved that Martin's packaging principles are jointly unsatisfiable for the resulting configuration — specifically, CCP and REP cannot both be satisfied (paper 2).

This third paper applies the Independent Variation Principle (IVP) to the same five-element setup and obtains two results from a single application.

Result 1: DIP → ISP, formalized in IVP terms

The first companion paper proved the structural biconditional: ISP ↔ per-client DIP. This paper formalizes the forward direction (DIP implies ISP) in IVP terms. Each interface slice shares its client's change-driver assignment. The IVP biconditional (elements co-reside iff they share driver assignments) closes the proof: the slices are disjoint because the clients belong to different modules. IVP adds formalism to one direction of a valid structural biconditional; it is useful here but not indispensable.

Result 2: A unique modularization

This is where IVP is essential.

Five elements: provider A, clients B and C, interface slices I_B and I_C. Three distinct driver assignments: {γ_ord} for B and I_B, {γ_rep} for C and I_C, {γ_ord, γ_rep, γ_impl} for A.

IVP-3 (elements with different driver assignments cannot co-reside) and IVP-4 (elements with identical driver assignments must co-reside) together admit exactly one partition:

Module B: B and I_B (both driven by γ_ord)
Module C: C and I_C (both driven by γ_rep)
Module A: A alone (composite: γ_ord, γ_rep, γ_impl)

Each interface slice lives with its client — not as a design preference, but as a consequence of the axioms applied to the causal structure of change.

What this settles

The packaging paper showed that eight principles — DIP, ISP, and six packaging principles (REP, CCP, CRP, ADP, SDP, SAP) — give three incompatible answers (with client, with provider, own module) and no meta-criterion for choosing. IVP eliminates two of the three by deriving the answer from Γ.

If two engineers disagree about where I_B belongs, the disagreement traces to a disagreement about Γ — about what can cause I_B to require modification. That is an epistemic question about the system, not a design preference. IVP converts a judgment call into a falsifiable claim.

What IVP's placement produces

The paper verifies that the unique IVP partition delivers:

Change isolation: a change to γ_ord modifies Module B (containing B and I_B) and nothing else. Module C is untouched.
No shotgun surgery: the pathology that scattered interface placement creates is eliminated by construction.
Acyclic dependencies in the provider–client subgraph: A depends on Module B and Module C (for the interface specifications it implements). Neither client module depends on A. No cycle exists in this subgraph.
Independent deployability: each module can be released independently.

The paper

"The Interface Segregation Principle Is a Corollary of the Dependency Inversion Principle --- A Formal Proof via the Independent Variation Principle"

Paper: https://zenodo.org/records/19641242
Companion 1 (ISP = DIP, structural): https://zenodo.org/records/19633560
Companion 2 (packaging unsatisfiability): https://zenodo.org/records/19636635

Companion 1 dev.to article: SOLID: ISP Is Just DIP Applied Twice
Companion 2 dev.to article: SOLID's Packaging Principles Are Jointly Unsatisfiable

The first paper showed ISP and DIP produce the same structure. The second showed SOLID's principles can't agree on where to put it. This one shows IVP can.

If you think the unique partition is wrong — that I_B belongs somewhere other than with B — I'd like to hear the argument. What change driver does I_B respond to, if not B's?

SOLID's Packaging Principles Are Jointly Unsatisfiable

Yannick Loth — Fri, 17 Apr 2026 22:40:47 +0000

If you know a software architect, a professor who teaches SOLID or packaging principles, or anyone who takes design principles seriously — I'd appreciate you sharing this with them. The argument needs to be challenged by practitioners and researchers alike.

A companion paper showed that ISP is a corollary of DIP at the class level. That settles which elements exist. It doesn't settle where they live in the package structure.

The paper I'm announcing here asks that question — and provides a formal proof that Martin's packaging principles cannot be applied simultaneously in general, and are in fact contradictory for a common class of dependency configurations.

The setup

Five elements: a provider A implementing two client-specific interfaces I_B and I_C, and two clients B and C depending on their respective interfaces. This is the minimal non-trivial DIP/ISP-compliant configuration — and a routine dependency pattern in object-oriented software.

52 ways to partition five elements into packages. Martin gives us eight principles (DIP, ISP, and six packaging principles: REP, CCP, CRP, ADP, SDP, SAP) to narrow the space.

The result

CCP and REP are jointly unsatisfiable.

CCP says: elements that change for the same reasons belong in the same package. Under DIP's ownership clause, I_B changes for the same reasons as B. So CCP puts I_B with B.

REP says: every package must be a viable unit of reuse — no consumer should be forced to accept elements it doesn't use. A must implement I_B, so A's package must depend on whichever package contains I_B. If I_B is packaged with B (as CCP requires), A is forced to take a dependency on B even though it never uses B. REP is violated.

No partition satisfies both. The proof is two steps, and it generalizes to any system where a provider serves two or more clients through client-specific interfaces.

It gets worse

Martin presents CCP, CRP, and REP as a "tension triangle" — three principles pulling in different directions, with the architect choosing which vertex to sacrifice. This sounds like a navigable trade-off space. It isn't.

Dropping REP from the triangle still yields zero satisfying partitions: CCP and CRP together remain unsatisfiable for the same configuration. Dropping CRP fares no better — the CCP/REP conflict that started this analysis is still there, unresolved. Only dropping CCP produces any solutions at all, and even then five partitions survive with no principle left to select among them. Two of the three escape hatches lead nowhere. The triangle has no navigable interior.

Adding DIP back into the picture doesn't rescue things. The co-location reading contradicts REP; the examples reading contradicts ISP; and the ownership reading adds no packaging constraint at all. The only DIP interpretation that doesn't eliminate the five surviving partitions is the one that stays silent on where packages should go.

Every recommendation is self-defeating

The three natural placements — with client, with provider, own package — each have principled support and principled condemnation from within the same framework. The principles don't just fail to agree on a winner; they actively indict every candidate they put forward.

Why this matters

If no packaging satisfies all principles, then any system containing a multi-client provider configuration violates at least one principle at every point in its history. The concept of "technical debt" implies a principled ideal to return to. For packaging, no such ideal exists.

Students who learn SOLID and the packaging principles as a coherent methodology will attempt to satisfy all of them, fail, and draw one of two wrong conclusions: (a) "I'm not skilled enough yet," or (b) "principles are just guidelines." Neither is correct. The correct conclusion — that these specific principles are collectively unsatisfiable — has not been available because the unsatisfiability was never demonstrated.

The paper

"SOLID: Where Do Client-Owned Interfaces Live? DIP, ISP, and the Packaging Principles"

Paper: https://zenodo.org/records/19636635
DOI: 10.5281/zenodo.19636635

Can you find a packaging of any multi-client provider configuration that satisfies CCP and REP simultaneously? If you think the formalization is too strict — that CCP should be a preference rather than a constraint — what does it mean to call something a "principle" if it can always be overridden by judgment?

SOLID: ISP Is Just DIP Applied Twice

Yannick Loth — Fri, 17 Apr 2026 16:40:16 +0000

If you know someone who teaches or researches software design principles, I'd appreciate you sharing this — the argument needs to be challenged by people who take SOLID seriously.

The Interface Segregation Principle (ISP) is widely taught as the fourth independent letter in SOLID. I've written a short paper showing it isn't independent at all: it is a special case of DIP's ownership clause applied once per client–provider edge.

Once both principles are stated precisely enough to reason about formally, the argument is straightforward. DIP's ownership clause says the client defines the interface it depends upon. Apply that to one client: you get one client-specific interface. Apply it to a second client of the same provider: you get a second, different interface. The provider now implements both, each client sees only its own slice, and no client depends on methods it doesn't use — which is exactly what ISP prescribes. At the class level, the two principles produce the identical structure: the same classes, the same interfaces, the same dependency and implementation relationships.

The converse also holds: any ISP-compliant segregation is structurally indistinguishable from the result of applying DIP's ownership clause per client.

I'm not saying that naming ISP is useless — naming the corollary directs attention to the per-client application of DIP, which textbooks consistently underemphasize. The claim is narrower: ISP prescribes no design action that per-client DIP doesn't already prescribe.

The paper also examines why this connection went unnoticed for nearly thirty years. The most fundamental reason is that both principles were stated as informal design directives illustrated by examples, making logical derivation impossible until they are stated precisely. Other factors include DIP's single-client framing, ISP's status as the least-scrutinized SOLID principle, and the strong prior created by the five-letter acronym.

Building on observations by Henney, Oldwood, Kaminski, and North that SOLID's principles overlap, I traced a specific derivation that, to my knowledge, has not been identified before: DIP's ownership clause applied per client is ISP.

The full structural proof (at the class level), worked example, and historical analysis are freely available:

"The Interface Segregation Principle Is a Corollary of the Dependency Inversion Principle: A Structural Proof"

Paper: https://zenodo.org/records/19633560
DOI: 10.5281/zenodo.19633560

At the class level, is there a case where ISP prescribes a different structure than per-client DIP? If you think ISP adds something at other levels (packages, APIs, services), I'd be interested in that too — the paper's scope is class-level, and extensions are future work.

Process-First Design and the Independent Variation Principle: Two Paths to the Same Territory

Yannick Loth — Wed, 15 Apr 2026 10:04:04 +0000

In response to Sergiy Yevtushenko's "The Quiet Consensus" and "Java Backend Design Technology: A Process-First Methodology"

Sergiy Yevtushenko's two recent articles make a concrete empirical observation: practitioners from F#, Rust/TypeScript, Java, Scala, and .NET have independently arrived at a shared structural insight about software decomposition. The insight is that processes — not data entities — are the more natural primary unit. Each practitioner he cites — Scott Wlaschin, Rico Fritzsche, Roman Weis, Sandro Mancuso, Jimmy Bogard, Debasish Ghosh — arrived at this conclusion from within their own tradition, without coordinating, solving problems at different scales and in different domains.

Independent convergence of this kind is methodologically significant. It suggests that the structural insight is not an artifact of a particular language or paradigm, but a response to a genuine property of the design problem itself. The problem, as Sergiy frames it, is that entity-first decomposition creates coupling through shared data models, and that coupling grows as the system grows. Process-first decomposition scopes data types to the processes that use them, so that changes in one process's requirements do not propagate through another process's code.

I have been developing a framework — the Independent Variation Principle (IVP) — that approaches the same structural territory from a different angle. This article examines where the two approaches meet, where they differ, and what each contributes.

The process-first framework

Sergiy's eight-question framework extracts a process structure from a feature description: what triggers the process, what data it needs, what success and failure look like, what its steps are, which steps depend on each other, whether there are conditional paths, and whether there is collection processing. The answers produce typed inputs, typed outputs, typed failure modes, step interfaces, and a dependency structure among the steps.

The dependency structure is the key output. Steps whose outputs are independent of each other can be composed in parallel. Steps where one requires the output of another must chain sequentially. The resulting composition — expressed as a data dependency graph using three operators (Sequential, ALL, ANY) — maps to code. Sequential becomes flatMap. ALL becomes a fork-join. ANY becomes a fallback that takes the first successful result.

The knowledge-gathering framing underlying this methodology has a structural consequence that extends beyond the surface description. Each step acquires a piece of knowledge. The process ends when enough knowledge has accumulated to formulate a response — success if the knowledge supports it, failure otherwise. A declined payment is not a mechanical error; it is a learned fact, and the process's response to it is structurally the same as its response to a successful payment, just with a different answer. This makes the semantics of failure modes explicit in the composition rather than leaving them as exception handling layered over a happy path.

The consequence for data modeling follows directly: rather than asking what data exists in the system, you ask what this process needs to know. Types are scoped to processes. Entities emerge afterward as the intersection of processes that need the same persistent facts. To use Sergiy's seat example: what booking needs to know about a seat differs from what pricing needs to know, which differs from what reservation management needs to know. A shared entity that serves all three is a compromise that fits none of them precisely.

The Independent Variation Principle

IVP starts from a different question: what causes each element of a software system to require modification? For each element, there is a set of change drivers — domain rules, regulations, operational constraints, anything that, when it changes, forces that element to change. The principle states that elements with the same set of change drivers belong in the same module, and elements with different sets belong in different modules.

Formally, this is a mapping Γ from elements to their driver sets. Two elements e and e′ belong in the same module if and only if Γ(e) = Γ(e′). The module structure that satisfies this condition is the partition of the element set induced by driver-set equality. This partition is unique given a fixed driver assignment, and it is a fact about the causal structure of the domain rather than a design preference.

The practical consequence is that IVP provides a criterion for adjudicating boundary decisions. When two engineers disagree about whether two elements belong together, the disagreement can be localized: instead of arguing about whether the boundary feels right, they are arguing about whether the elements share change drivers. That is a question domain expertise can investigate, and it is a question to which there is a fact of the matter.

Where the two frameworks meet

Both frameworks address the question of which elements of a software system should be grouped together and which should be separated. Sergiy's framework identifies what each process needs and scopes types accordingly. IVP asks what causes each element to change and groups by driver-set equality. The two approaches converge on the same structural observation: elements whose change is driven by independent forces should be separated, and elements driven by the same forces should be grouped.

The "entities are discovered, not invented" claim in process-first design maps onto what IVP would predict from driver analysis. Two processes share a persistent type when they share facts about the world governed by the same change drivers. If the price of a product changes for the same reasons regardless of which process queries it, the price data has a single driver set and belongs in a single location. If what booking calls a "seat" changes for logistics reasons and what pricing calls a "seat" changes for revenue management reasons, those are different driver sets, and the shared entity is a coupling that will surface as a coordination cost when either driver changes.

The knowledge-gathering framing and the driver analysis framing are also consistent at a deeper level. Knowledge is acquired by a process because the process needs facts about the world to formulate its response. Those facts are governed by domain rules, regulations, and operational constraints — precisely the forces IVP formalizes as change drivers. A process that needs to know whether a customer's credit score qualifies them for a loan is sensitive to credit scoring rules; if those rules change, the process changes. The two descriptions refer to the same underlying causal structure.

Where the two frameworks diverge

The eight-question framework is primarily an elicitation tool. Given a feature description, it extracts a process structure: the types, the failure modes, the steps, and the dependency graph among the steps. For most of the questions, the extraction is fairly direct. Question 6 — which steps depend on each other — requires more judgment, and this is where the frameworks diverge in what they offer.

Determining step dependencies requires knowing the causal relationships among the pieces of knowledge the process is acquiring. Sometimes this is unambiguous. Validation must precede inventory checking because the inventory check needs to know what was requested. Other cases are less clear. Whether fraud detection runs in parallel with payment processing or gates it depends on the failure semantics of the system — on what the process is supposed to do if fraud is detected while payment is being processed — and on operational constraints that may not be stated in the feature description. Two engineers reading the same requirements may answer question 6 differently, and both compositions may satisfy the stated requirements while behaving differently under failure.

IVP does not resolve this question directly either, but it provides a lens for examining it. If fraud detection changes for regulatory compliance reasons and payment processing changes for financial settlement reasons, their driver sets are different. The question of how they should be composed then becomes a question about the protocol between two independently varying modules — a question about interface design rather than step ordering. The driver analysis does not determine whether to run them in parallel or sequentially, but it identifies that the design goal should be to minimize coupling between them, because they will change for different reasons and at different times.

What the two approaches contribute to each other

Process-first design contributes an elicitation methodology: a set of questions that, applied to a feature description, extracts a process structure that can be encoded in types and compositions. The data dependency graph notation makes the dependency structure explicit in a form readable by both developers and domain experts. The three operators — Sequential, ALL, ANY — cover the structural cases that arise in practice.

IVP contributes an adjudication criterion: a way to evaluate proposed boundaries by asking whether the elements on each side of the boundary share change drivers. This is useful when elicitation produces ambiguous results, when a proposed boundary is challenged, or when a composition has evolved over time and its original rationale is no longer clear.

The two approaches are compatible and, in practice, complementary. A team doing process-first design and arriving at a contested step boundary can apply driver analysis to determine whether the proposed boundary reflects genuine causal independence in the domain. A team doing driver analysis and trying to understand what types and compositions a boundary implies can use the process-first framework to elicit the process structure from requirements.

Neither framework tells you what the change drivers actually are. Driver analysis consumes a driver assignment and produces a partition — it does not produce the driver assignment from a requirements description. The eight-question framework extracts a process structure from a feature description — it does not tell you at what granularity to define the steps, or when two candidate steps should be merged or split. Both frameworks shift the locus of judgment from "what structure feels right?" to "what are the causal facts about this domain?" That shift is their shared contribution. Causal facts can be investigated with domain experts and updated as understanding develops. Structural intuitions about what feels right cannot be grounded in the same way.

The convergence Sergiy documents across languages points toward a structural insight that both frameworks are approaching from different directions. The insight is that software boundaries should track causal independence in the domain. Process-first design operationalizes this by asking what each process needs to know. IVP operationalizes it by asking what causes each element to change. That they arrive at the same structural territory from different starting points is additional evidence that the territory is real.

Sergiy Yevtushenko's articles: The Quiet Consensus · Java Backend Design Technology

Independent Variation Principle (Preprint): doi.org/10.5281/zenodo.17677315

Which Java Construct Should You Use? Let Change Drivers Decide

Yannick Loth — Sat, 11 Apr 2026 18:46:00 +0000

A change driver is anything that, when it changes, forces an element of a system to change.
The Independent Variation Principle (IVP) constrains how modules and their elements relate to these drivers: elements sharing a module must have the same driver assignment, and elements with different driver assignments must live in different modules.

Applied to Java constructs, the lens separates essential coupling — the drivers the situation actually requires — from accidental coupling — the drivers the chosen construct drags in for reasons that have nothing to do with the situation.
Picking the right construct is picking the one whose realization carries only the essential drivers.
Throughout the article, "before" constructs carry accidental coupling (typically an implicit outer-instance reference, a synthetic class file, or a mutation channel the situation does not need); "after" constructs remove the accidental artifacts and keep only what the situation requires.

Non-static inner class

A non-static inner class carries an implicit OuterClass.this reference, generated by the compiler whether or not the inner class body ever uses it.
The structural consequence is that the inner class's driver set automatically includes all of the outer class's change drivers.
If OuterClass has three independent reasons to change, the inner class inherits all three.

Non-static inner classes are often the right choice.
When the inner class's behavior must observe live changes to the outer instance's state — not just read its fields once, but see every write that happens between construction and use — the driver import is warranted: any change to how the outer tracks that state forces a corresponding change in the inner class.
The canonical case is a fail-fast iterator over a mutable collection:

// Warranted: RingBufferIterator must observe structural modification of the
// buffer during iteration — fail-fast, single-threaded. modCount is
// outer-instance state that the iterator reads on every step; the coupling
// to the outer instance is structural, not convenience.
class RingBuffer<T> {
    private final Object[] elements;
    private int head;
    private int size;
    private int modCount;   // bumped before every structural change

    public Iterator<T> iterator() {
        return new RingBufferIterator();
    }

    public void add(T value) {
        modCount++;          // bump first, then mutate
        // ... store into elements[(head + size) % elements.length]
        size++;
    }

    class RingBufferIterator implements Iterator<T> {
        private int cursor = 0;
        private final int expectedModCount = modCount;

        @Override
        public boolean hasNext() {
            return cursor < size;
        }

        @Override
        @SuppressWarnings("unchecked")
        public T next() {
            if (modCount != expectedModCount) {
                throw new ConcurrentModificationException();
            }
            if (cursor >= size) {
                throw new NoSuchElementException();
            }
            return (T) elements[(head + cursor++) % elements.length];
        }
    }
}

The modCount check is what makes the outer coupling load-bearing: a static iterator that received elements, head, and size as constructor parameters would see a frozen snapshot and could not detect mutation.
Because the iterator must observe modCount on every next(), it must hold a live reference to the buffer — that is exactly what a non-static inner class provides.

Essential coupling: live access to the buffer's modCount and backing array.
Accidental coupling introduced by the non-static inner class: none — the compiler-synthesized this$0 reference is exactly what the fail-fast check needs. A static nested class would achieve the same thing by taking an explicit RingBuffer<T> constructor parameter; the reference would be user-declared instead of compiler-synthesized, but otherwise identical. For this situation the non-static syntax is the right choice precisely because the outer-instance reference it imports is essential.

The case to watch for is the subset where the inner class body never references OuterClass.this at all — there the compiler-generated outer reference is present but the body does not exercise it, and promoting the class to static (or extracting it entirely) removes the reference at no other cost.

// Unwarranted: Address is a plain data bundle whose definition depends
// only on what an address is — street, city, postal code. Address does
// not reference any Customer field, yet the Java compiler adds an implicit
// Customer.this reference to every Address instance. Java serialization
// of a non-static inner class drags the enclosing Customer along; tests
// that want an Address must construct a Customer first; and every
// Address holds a reference preventing its enclosing Customer from
// being collected.
class Customer {
    private String name;
    private String email;

    class Address {
        String street;
        String city;
        String postalCode;
    }
}

// Corrected: Address is a top-level record. Its definition depends on
// the concept of an address, not on which entity happens to have one.
// The same Address type is reusable across Customer, Supplier, Shipment,
// serializable on its own, and testable without any outer instance.
record Address(String street, String city, String postalCode) {}

class Customer {
    private String name;
    private String email;
    private Address address;
}

Essential coupling: the address schema (street, city, postal code) and whatever validation or formatting rules apply to addresses.
Accidental coupling introduced by the non-static inner class: a compiler-synthesized this$0 field pointing at a Customer instance, plus the constructor parameter that populates it. Address's body never references either; the compiler emits them because the JLS requires them of every non-static inner class, regardless of whether the body uses them.
The top-level record removes those artifacts entirely — no enclosing-instance field, no constructor parameter for one, no binding to any Customer contract. Every Address now depends on the essentials and nothing more.

Static nested class

A static nested class has no implicit outer reference and no coupling to the enclosing instance.
Its driver set is its own.
Use it when code needs to reside inside the enclosing type for visibility reasons — package-private access, logical grouping — but varies independently of the outer class.
If a non-static inner class never references the outer this, promoting it to static removes the compiler-synthesized outer reference at no other cost.

A linked-list Node is the canonical case.
Each node stores a value and a pointer to the next node — nothing it does depends on the particular list instance it belongs to, and promoting it from non-static to static lets the node be used across list instances, serialized independently, and tested in isolation:

// Before: Node is non-static. It implicitly shares LinkedList's
// type parameter T, but the compiler also adds a synthetic this$0
// field of type LinkedList<T> to every node instance — even though
// Node's body does not depend on the list it happens to live in.
class LinkedList<T> {
    Node first;   // implicitly Node of the enclosing LinkedList<T>
    Node last;

    class Node {
        T value;
        Node next;

        Node(T value) { this.value = value; }
    }

    void add(T value) { /* ... */ }
}

// After: Node is static and generic in its own right. It carries
// only value + next; no synthetic enclosing-instance reference,
// no dependency on any particular list.
class LinkedList<T> {
    Node<T> first;
    Node<T> last;

    static class Node<E> {
        E value;
        Node<E> next;

        Node(E value) { this.value = value; }
    }

    void add(T value) { /* ... */ }
}

Essential coupling: a value cell and a pointer to the next node.
Accidental coupling introduced by the non-static form: a this$0 field pointing at a specific LinkedList instance, and its constructor parameter. Node's body needs neither — a node's behavior does not change based on which list it happens to be in.
The static form keeps only the essential artifacts. This is the choice java.util.LinkedList makes in the JDK source: its private Node is static, for the same structural reason.

Lambda

A lambda closes over exactly what its body references.
Its driver set contains only the drivers of what it explicitly captures.
A this reference inside the lambda body lexically binds to the enclosing instance, not to any identity the lambda introduces, and the enclosing instance is captured only when the body actually uses it.
Lambdas are the correct form for single-operation, stateless behavior.

// Both forms sit in a non-static context (an instance method on some service).
// batchId is a local value — captured by reference by whichever form we pick.
final long batchId = nextBatchId();

// Before: anonymous class — the compiler emits a synthetic class file
// (Outer$1.class), and because we are in a non-static context every
// instance also carries an implicit Outer.this field alongside the
// captured batchId, regardless of whether run() ever uses it.
executor.submit(new Runnable() {
    @Override
    public void run() {
        System.out.println("processing batch " + batchId);
    }
});

// After: lambda — the compiler extracts the body into a private static
// method; LambdaMetafactory generates a hidden class (no .class file on
// disk) holding only batchId. No synthetic Outer.this field is added,
// because the body does not reference anything on the enclosing instance.
executor.submit(() -> System.out.println("processing batch " + batchId));

Essential coupling: the captured batchId value and whatever the body actually references.
Accidental coupling introduced by the anonymous class: a this$0 field pointing at the enclosing instance, emitted whether or not run() uses it, because the anonymous class sits in a non-static context.
The lambda pays for the enclosing-instance reference only when the body actually needs it — if the body touched this.someField, the compiler would emit the lambda body as an instance method and bind the receiver; when it does not, as here, nothing is bound. The anonymous class binds unconditionally.

The JVM reflects this structurally.
Lambdas are not compiled as anonymous classes.
The compiler extracts the body into a private static method in the enclosing class, then emits an invokedynamic instruction at the lambda site.
At runtime, LambdaMetafactory generates a hidden class — a class with no classloader-visible name, no .class file on disk, eligible for garbage collection when no longer referenced — that implements the target SAM interface backed by the static method.
No outer instance is captured unless the body actually uses it.

A SAM interface (Single Abstract Method) is any interface with exactly one abstract method: Runnable, Comparator<T>, Predicate<T>, Function<A,B>.
Any lambda can be used wherever such an interface is expected.

Method reference

A method reference (ClassName::method, instance::method) introduces no new structural unit.
The referenced method already exists with its own driver set; the reference passes behavior without adding coupling.
Prefer it over a delegating lambda that does nothing but forward the call:

// Delegating lambda — adds nothing, obscures the reference
list.forEach(x -> logger.log(x));

// Method reference — explicit, no additional coupling
list.forEach(logger::log);

Essential coupling: the existing Logger.log behavior, for each element of the list.
Accidental coupling introduced by the delegating lambda: a wrapper method on the enclosing class whose only purpose is to forward x into logger.log(x).
The method reference skips the wrapper — the compiler binds invokedynamic directly to Logger.log with logger as the bound receiver. The wrapper artifact disappears from the compiled output, and so does anything that might make the wrapper itself a maintenance liability.

Anonymous class

An anonymous class generates a named .class file, always captures OuterClass.this in a non-static context, and carries the full infrastructure of a class definition.
The situation that genuinely warrants one — needing state, multiple methods, and no desire for a named type, simultaneously — is less common in Java 25 than it was pre-lambda, though it still arises in listener-heavy and UI codebases.
When it arises, a static nested class with a descriptive name communicates intent more clearly.
For the common case of implementing a single-method interface with no state, a lambda is structurally correct.

// Before: anonymous class — a synthetic class file plus, in a non-static
// context, an implicit Outer.this reference that the comparator's body
// does not use.
Comparator<Order> byPriority = new Comparator<Order>() {
    @Override
    public int compare(Order a, Order b) {
        return Integer.compare(b.priority(), a.priority());
    }
};

// After: lambda — same behavior, no synthetic class file, no Outer.this
// unless the body references it. Driver set is bounded to what the body
// actually uses: Order.priority() and Integer.compare.
Comparator<Order> byPriority = (a, b) -> Integer.compare(b.priority(), a.priority());

Essential coupling: the two Order arguments and the priority comparison.
Accidental coupling introduced by the anonymous class: a this$0 field pointing at the enclosing instance, emitted because the comparator sits in a non-static context, even though compare never references it.
The lambda removes the enclosing-instance binding. A separate, orthogonal refactor replaces the body with Comparator.comparingInt(Order::priority).reversed(); that is a library-idiom choice and does not change the accidental-coupling picture — the lambda form already removed the accidental part.

Record

A record is an immutable data carrier whose driver set is bounded to the drivers of its declared components.
The only things that can force a record to change are changes to the identity or semantics of those components.

Mutability introduces a hidden class of change drivers: anything that writes to a mutable field becomes a change driver for every reader of that field.
In a shared mutable object, the driver set of every holder is infected by the write patterns of every other holder.
Records eliminate this class of coupling by construction.

// Mutable: any writer is a change driver for any reader
class Money {
    BigDecimal amount;
    Currency currency;
}

// Record: driver set bounded to amount and currency semantics
record Money(BigDecimal amount, Currency currency) {}

Essential coupling: an amount and a currency, and whatever operations the domain needs on them.
Accidental coupling introduced by the mutable class: a mutation channel — every holder of a Money reference is coupled to every other holder's write pattern, because the language lets any code with a reference rewrite the fields. Synchronization discipline exists only in convention, not in the class.
The record closes the mutation channel at the language level. The fields are final, construction is canonical, and no write path exists for other holders to cause surprises on this one. The remaining coupling is exactly what the domain requires.

Java 25 records support compact constructors, custom accessor methods, and implements clauses, handling most data-carrier needs that previously required a hand-written immutable class.

Sealed interface with pattern matching

A sealed interface restricts which classes can implement it, making the driver space explicit and finite.
An instanceof chain imports the driver set of every concrete type into the caller and silently becomes incomplete when a new subtype is added:

// Caller's driver set grows to include the union of Γ(Circle), Γ(Rectangle), Γ(Triangle)
if (shape instanceof Circle c) { ... }
else if (shape instanceof Rectangle r) { ... }
// New subtype added later — silently falls through

A sealed hierarchy with exhaustive pattern matching bounds the caller's coupling to the interface contract.
The compiler enforces exhaustiveness: adding a permitted subtype requires every switch site to acknowledge it.

// Caller's driver set is Γ(Shape) — the sealed interface only
switch (shape) {
    case Circle c    -> ...
    case Rectangle r -> ...
    case Triangle t  -> ...  // required once Triangle is permitted
}

Java 25 pattern matching in switch covers deconstruction patterns, guarded cases, and primitive patterns, giving sealed hierarchies the expressive range to handle realistic variant spaces.

Essential coupling: the caller varies with each permitted Shape subtype — that is unavoidable and equally present in both forms.
Accidental coupling introduced by the instanceof chain: the risk that a new subtype is added somewhere in the codebase and the chain silently misses it. That failure mode is not in the shape of the code itself — it is in the gap between what the compiler checks and what the source says.
The sealed switch closes the gap: the compiler knows the permitted subtypes from the sealed ... permits ... declaration and refuses to compile the switch until every permitted subtype is either handled or covered by a default. A new variant forces a visible compile error rather than a silent runtime fall-through. The coupling to the variants remains essential; the accidental failure mode is gone.

Optional and Result

In plain Java without static nullability tooling, null is an invisible driver: callers must defensively check for it without any compile-time signal that the absent case exists.
(JSpecify, the Checker Framework, and NullAway have been closing this gap at the annotation level; Optional<T> closes it at the type level, which is what follows here.)
Optional<T> makes the driver explicit in the type and propagatable via map and flatMap:

// null: absent-case driver invisible at call site
String city = user.getAddress().getCity(); // NullPointerException possible

// Optional: driver explicit, propagation compositional
Optional.ofNullable(user)
    .map(User::getAddress)
    .map(Address::getCity)
    .ifPresent(this::processCity);

A checked exception imposes the same problem on error conditions: every intermediate caller in the stack must declare it, importing the error driver regardless of whether that caller handles it.
A Result<T, E> type — not part of the JDK, but available via Vavr or straightforward to write by hand — makes the error a value.
Intermediate callers propagate it via map and flatMap; only the caller that actually handles the error depends on the error type's change drivers.

Result<T, E> is the right tool in two situations.
First, when the failure is a domain concern the caller should branch on — a payment decline, a validation failure, a lookup miss with multiple possible reasons.
Second, when your module sits on a boundary and an upstream system can hand you values it contractually should not — a null where the documentation promised non-null, a response with a missing required field, a database row with a broken invariant.
In both cases the failure is data from your module's perspective: you cannot fix the upstream, you can only observe it and give your caller a typed value to decide with.
The discriminator is trust: a boundary is the line past which you cannot assume contracts hold, and Result is the shape that lets the boundary absorb a violation without propagating a surprise into deeper code.

For bugs in your own code — invariants your module was supposed to enforce and did not, unreachable code that was reached, impossible states, broken casts — an unchecked exception remains the right form.
The JVM's exception machinery is built for this case: it preserves a stack trace at the point of violation, propagates loudly to a top-level handler, and does not force innocent intermediate callers to pattern-match on a failure that means their collaborator is broken.
Wrapping a bug in a Result.Failure loses the stack trace, silently carries the broken state through combinator chains, and delays the crash past the point where it would have told you what went wrong.
The trade-off is real: Result gives up stack traces, demands a dependency or a hand-rolled type, and requires the team to adopt a paradigm shift around error handling — all of which is worth it for expected failures at boundaries, and none of which is worth it for bugs you actually want to find.

Enum

An enum is the correct construct when the driver space itself is finite and closed, the variants carry no per-instance state, and the entire variant set is a stable fact about the domain (days of the week, HTTP method verbs, file open modes).
When the variants need per-instance fields or independent evolution, a sealed interface over records is the better fit: each permitted record carries its own drivers, composition is free, and new variants can be added without touching a shared constant declaration.
The dividing line is stateful variance: enums for closed stateless sets, sealed hierarchies for closed stateful ones.

The direction of Java's evolution

Each major Java addition since Java 8 has moved toward constructs that reduce the gap between what the language forces you to couple to and what the structural situation requires.
Lambdas gave single-operation behavior a minimum-footprint form.
Optional made absence drivers explicit in the type.
Records eliminated mutable-state coupling.
Sealed interfaces bounded the driver space to the declared set.
Pattern matching made exhaustive dispatch over sealed driver spaces compiler-enforced.
Hidden classes removed the last artifact of the anonymous-class era from lambda compilation.

Read through IVP's lens, the direction is legible: each addition gives developers a way to express a structural situation with a narrower set of compiled artifacts than the construct it replaces, which is the same thing as saying less accidental coupling.
Whether every JEP was deliberately motivated by coupling analysis is beside the point — the effect, observed across the language's evolution, is that the gap between what the constructs force you to couple to and what the situation requires has narrowed.
Framework and ecosystem realities push in the other direction: JPA entities still require mutability and no-arg constructors, reflection-based serialization libraries still call setters, Spring-managed beans still participate in proxy machinery that forbids final.
The language's direction is visible, but the ecosystem constrains which parts of it a given codebase can adopt.
The practical split in a typical Java 25 service is records for value objects and DTOs, sealed interfaces for domain hierarchies the developer fully controls, and mutable classes for entities and beans the framework manages.

The decision

The question is always the same: does this construct force more coupling than the situation requires?
The answer determines the choice.
If the code needs the outer instance's state, a non-static inner class is warranted.
If it needs state or multiple methods but not the outer instance, a static nested class is correct.
If it needs neither, a lambda is the right form.
Records replace mutable data carriers.
Sealed interfaces replace open hierarchies when the variant space is closed.
Optional and Result replace invisible null and exception drivers with explicit types.
Each substitution is structural, and the structure is what determines how much the code costs to change.

Three Questions Before You Add a Microservice — and Why They All Collapse Into One

Yannick Loth — Tue, 07 Apr 2026 16:59:05 +0000

A recent LinkedIn post from John Crickett has been making the rounds. It offers three questions to ask before adding another microservice:

Does this need to be a service?
Does this need to be its own service?
Does this need to be its own service right now?

Crickett credited Craig Ferguson, the comedian, for the format — Ferguson has a bit about three questions a man should ask himself before he speaks. The post is in that register: deliberately light, deliberately compressed, the kind of aphorism a practitioner can carry in their head into a Monday-morning design meeting. Crickett's questions have spread because they work. They surface the right conversation in teams that might otherwise never have it.

What I want to do is unpack what the aphorism is compressing. My claim isn't that Crickett's questions are wrong or incomplete — it's that they're pointing very precisely at something a formal theory of modularization can name. And the something they're pointing at is more unified than the three-part structure suggests: the three questions turn out to be three natural-language phrasings of one structural question. Seeing why is, I think, the most interesting thing you can do with the post.

Let me walk through it.

The criterion: same drivers together, different drivers apart

I'll use the Independent Variation Principle (IVP) as the lens. You don't need to have read the formalization to follow this article. The idea in plain words is:

Every element in a system — every function, every class, every module — has a set of change drivers. A change driver is anything that, when it changes, forces that element to change. Requirements, domain rules, regulations, performance targets, deployment constraints — any cause of future modification.

The principle says: group together elements that share the exact same set of change drivers, and separate elements whose sets of change drivers differ.

That's it. Once the driver sets are fixed, the comparison is binary: two elements either have the same set of change drivers or they don't. No gradient, no threshold, no "similar enough." Same set → together. Different set → apart.

That binary comparison is what distinguishes this principle from SRP's "one reason to change" or CCP's "things that change together." Both of those formulations leave the comparison itself underspecified — reason and change together admit interpretations a team can argue about indefinitely. IVP shifts the imprecision: the comparison step becomes mechanical, but the driver discovery step — figuring out what's actually in the driver set for a real element — still requires deep engineering judgment. The principle doesn't make the hard work disappear. It moves it from "how do we compare these modules?" to "what are the actual causes of change for these elements?", which is the question domain expertise can answer.

We'll come back to the discovery step. The point for now is that once the inputs are fixed, the answer follows. That's a stronger guarantee than the classical principles offer, even if it isn't the magic-wand guarantee absolute decidability would suggest.

Question 2 first, because it's the cleanest

Let me take the questions out of order and start with Q2: "Does this need to be its own service?"

Read literally, Q2 is a yes-or-no question. "Its own" means separate from existing services — a binary property. And that maps directly onto the principle's criterion:

Is there an existing service whose set of change drivers equals the set of change drivers for this new capability?

If yes: the new capability belongs inside that existing service from a structural standpoint. Putting them in separate services would mean two services that must change in lockstep whenever any of their shared drivers change — which is the structural shape of a distributed monolith. Other constraints (security boundaries, regulatory isolation, organizational ownership) may still justify keeping them apart, but those would be explicit trade-offs against the structural ideal, not refutations of it.

If no: the new capability belongs in a separate module from a structural standpoint. Keeping it inside an existing service would mean that service now has elements changing for different reasons, tangling concerns that should be independent.

Q2, read structurally, is asking exactly this. It doesn't say "change drivers," but the question it poses is the one the principle formalizes. What it lacks is a method for answering — it tells you to ask the question but doesn't tell you how to compute the answer. We'll come back to that.

Question 3: the temporal illusion

Now Q3: "Does this need to be its own service right now?"

This looks like it adds a new dimension — timing — to Q2. On closer inspection, it doesn't. It adds nothing the principle can see.

Here's why. The principle evaluates a module structure against the current set of change drivers. It has no temporal dimension. It doesn't care about drivers you imagine will exist in the future, or drivers you had last year, or drivers you might have if the product succeeds. It cares about the drivers that actually cause modification now, in the system as it exists.

So "right now" is either redundant or incoherent:

Redundant if the asker means "given the drivers we actually have today." That's what the principle already assumes. Q3 reduces to Q2.
Incoherent if the asker means "given drivers we imagine might emerge later." The principle doesn't accept imagined future drivers as inputs. If you don't have evidence that a driver exists and applies to these elements, it isn't in the set, and speculating about it doesn't put it there.

There's a third reading: "should we do this decomposition work in this sprint versus later." That's a project scheduling question, and it has nothing to do with modularization theory. You might defer the work because you're busy, because the team is tired, because another priority dominates — those are real reasons, but the principle says nothing about them.

So Q3 either collapses into Q2 (structural reading) or dissolves into something outside the theory's scope (scheduling reading). Either way, it adds no new structural content.

There is, however, something the "right now" phrasing accidentally brushes against, and it's worth saying explicitly — not as part of Q3, but as a warning about the "drivers we imagine might emerge later" reading above. IVP has a consequence sometimes called the knowledge theorem: the correct partition reflects the causal knowledge you actually have about the system's current drivers. When you add elements designed to serve drivers that don't yet exist — speculative extensibility points, plugin systems waiting for plugins, abstractions anticipating requirements that haven't arrived — those elements don't share drivers with anything real in the system. They land in their own cells, structurally disconnected from the rest, and they push real elements into shapes that accommodate hypothetical concerns rather than actual ones. The partition the principle produces over the enlarged element set is structurally incorrect relative to the system's actual causal reality.

That's a structural claim, not a moral verdict. The principle isn't saying "speculative design is bad." It's saying that a partition built on drivers that haven't materialized doesn't match the partition the system's actual change history will reward, and that mismatch shows up as elements getting touched together for reasons the structure didn't anticipate. Whether the cost of that mismatch outweighs the cost of waiting until the drivers are real is an engineering judgment IVP doesn't make for you. What IVP does say is that the cost is structural and not free. There's an important exception: extensibility justified by currently observed drivers — plugin systems for which plugins already exist, abstractions over already-shipping variations — is a different case. Those drivers are real, the elements that serve them have a place in the partition, and the principle has no objection.

So if Q3 is doing any work beyond Q2, it's this: don't import imagined future drivers into a decomposition you're making today. Decide based on what you actually know causes change in the system as it stands.

Q3 collapses into Q2.

Question 1: the technology trap

Now Q1: "Does this need to be a service?"

There's an intuitive reading of Q1 that makes it look orthogonal to the principle — that it asks about realization technology (service vs. library vs. in-process module) rather than about module boundaries. On this reading, the principle tells you the logical partition, and then a separate engineering decision picks how each module is deployed. Modularization and deployment are treated as two layers: first decide what goes with what, then decide how to ship it. It's a sensible-looking division of labor, and it's something close to the default mental model in much architecture writing.

I want to argue it's incomplete, and the gap it leaves is the one Q1 is actually pointing at.

The gap lies in what counts as a change driver. The two-layer reading tacitly restricts the driver set to functional drivers — business rules, domain concepts, user-facing requirements — and treats everything else as "non-functional" concerns that live downstream. But that split is a convention, not a principle. A change driver, in IVP's sense, is anything whose change forces a corresponding modification of the element. And architectural quality requirements clearly cause modifications:

"Must scale independently to 10,000 requests per second." If that target shifts — up to 100,000, or down to 100 — caching strategy, concurrency model, data structures, and possibly the storage layer have to change. It's a driver.
"Must survive the failure of neighboring components." If the failure-tolerance target changes, retry logic, circuit breakers, state replication, and idempotency guarantees have to change. It's a driver.
"Must be deployable without coordinating with team X." If that independence requirement changes, interface contracts, versioning strategy, and backward-compatibility code have to change. It's a driver.

These satisfy the definition of a driver in the same sense as "the tax code might change" or "the pricing model might be revised" do. There's no principled way to admit one kind and exclude the other.

But just admitting architectural-quality drivers into the set isn't by itself what reshapes the partition. There's an intermediate step that's easy to skip past: a quality requirement doesn't act on the system as an abstract force — it acts through concrete elements that implement it. A scalability target above what a single instance can handle isn't satisfied by wishing; some element has to actually distribute the work. A failure-isolation target isn't satisfied by intent; some element has to actually contain failures. A deployment-independence requirement isn't satisfied by good will; some element has to actually broker compatibility. These elements are real components with their own implementations and their own change profiles. They aren't optional decorations on the functional code; they're the concrete carriers of the quality requirements, and the quality requirements can't act on the partition without going through them.

The interesting question is what driver sets those carrier elements have. A circuit breaker's behavior is shaped primarily by the failure modes it guards against, the observability it reports to, and the retry policies it coordinates with. Its implementation responds to changes in those drivers, not to changes in the business rules of the service it fronts. (There's a real edge case here: a circuit breaker whose failure-classification logic is driven by business semantics — "treat this as a failure only for premium customers" — does have business drivers in its set. In that case the principle would correctly group it with the business logic, not with other infrastructure. The general claim isn't that infrastructure drivers and functional drivers never overlap; it's that they often don't, and where they don't, the partition reflects that.) A caching layer's drivers are cache-invalidation semantics and memory pressure, not the functional logic of what's being cached. When the typical case holds — when the carrier element's drivers are genuinely distinct from the functional element's — the principle separates them into different cells, and the resulting partition is different from the one functional drivers alone would produce.

This is where the service-versus-library choice connects to the partition rather than sitting after it. The principle determines the logical module boundary: which elements share a driver set and therefore belong in the same cell. Whether that cell can be realized as an in-process module is a separate question, answered by whether the drivers in the cell are operationally compatible with sharing a process. A driver that requires independent failure containment is not operationally compatible with in-process coexistence — failures inside one process take everything in that process with them, so the failure-isolation driver can't be made actionable inside a shared process. A driver that requires independent horizontal scaling is not operationally compatible with in-process coexistence — you can't scale one component of a process without scaling the whole process. These operational-compatibility judgments aren't part of IVP's formal apparatus; they're engineering facts about runtimes, processes, and networks. But they connect directly to the partition: when a cell's drivers include any whose operational requirements rule out shared-process realization, the only realization that lets all the drivers in the cell be satisfied at once is a separate deployable unit.

So the "is this a service?" question is really asking: when we account for the elements that carry the system's quality requirements, and we let the principle partition over the enlarged element set, does this element land in a cell whose drivers — functional and quality — collectively rule out sharing a process with anything else? That's the same shape as Q2 — is there an existing module this element's driver set matches? — but evaluated over the full driver set rather than just the functional one. The realization decision isn't downstream of the partition; it's the operational consequence of which drivers are in the partition's cells, evaluated against engineering facts about how those drivers can actually be served.

Q1 collapses into Q2.

One question, not three

Here's where we land. Crickett's three questions, read structurally, aren't three independent checks. They're three natural-language phrasings of the same underlying question:

Taking into account the full set of change drivers for this element — functional drivers and quality drivers alike — does its set of drivers equal that of some existing module? If yes, the structural answer is to merge. If no, the structural answer is to separate, and which realization (in-process module, library, separate service) the separated module needs is determined by which drivers are in its cell and how those drivers can be operationally served.

That's the whole decision, once the inputs are fixed. One question, one criterion, binary comparison. The principle's contribution is making the question precise: given an agreed-upon driver assignment, the answer is determined.

That precision is the gap classical principles haven't quite closed. Parnas, in his 1972 paper on decomposing systems into modules, came close — his "design decisions likely to change" is essentially a change driver in everything but the formal apparatus. The intuition was right; what was missing was the explicit treatment of driver-set equality as the criterion. SRP points at separation by reason-to-change but leaves "reason" undefined. Separation of Concerns points at orthogonal grouping but leaves "concern" undefined. CCP correctly targets co-variation but doesn't distinguish causal co-variation (shared drivers) from accidental co-modification (drivers that happened to fire together). All three are pointing at something genuine. What IVP adds is the formal apparatus that makes the criterion precise enough for two engineers who disagree to identify exactly what they disagree about — which driver applies to which element — rather than talking past each other about "reasons" and "concerns."

But here's the catch

The principle makes the question well-posed and decidable. It does not make the question answerable without expertise.

This is the part that matters for practitioners, and it's the part I want to be careful about. The principle consumes a driver set and produces a partition. It does not produce the driver set. Identifying what actually belongs in the driver set for a real system — which architectural qualities are genuine drivers versus current accidental properties, which functional requirements are real causes of future change versus one-time decisions, which deployment constraints are inherent versus incidental — is empirical work. It requires:

Performance engineering expertise to know which scaling drivers are real. Splitting a service "for independent scalability" when nothing in the system's actual or projected load suggests the element will ever need independent scaling means splitting on a driver that isn't there. The partition looks principled, but the input it rests on is imagined.
Reliability engineering expertise to know which failure-isolation drivers are real. Blast-radius concerns are drivers when there's a credible failure mode that actually needs to be contained; in their absence, they're a split justified by a driver the system doesn't have.
Capacity planning and load analysis to distinguish current properties from future causes of change. "It runs fast enough today" is not a driver. "It must maintain sub-10ms latency as traffic grows ten-fold over the next two years" is.
Deployment and organizational analysis to know which independence drivers are real. Team-autonomy is a driver when teams genuinely need to deploy independently; it isn't when the organization doesn't actually work that way.
Domain knowledge to identify the functional drivers without confusing them with implementation choices.

None of that is the principle. The principle has no method for deciding whether "must scale to 10K RPS independently" is a real driver or an imagined one. That determination comes from engineering disciplines IVP doesn't subsume.

The honest picture is: the principle plus quality knowledge together answer the question Crickett is pointing at. Neither alone does. Quality knowledge without the principle gives you a list of architectural concerns but no principled way to combine them into a partition. The principle without quality knowledge gives you a partition machine with no inputs. Both are common in isolation; the combination is rarer than it should be, and that's where the leverage is.

A worked example: 10,000 users and four servers

Let me make this concrete, because the interaction between capacity math and the principle is where a lot of confusion lives.

Suppose you're told: "this system must serve 10,000 concurrent users on hardware X." A natural question is: does the principle tell you how to modularize this? The honest answer is that the principle, on its own, has nothing to say about the number 10,000, or about hardware X, or about how many servers you'll end up running. It has no model of throughput, queuing, concurrency, or hardware characteristics. If you ask it "how many servers do I need?" it has no answer, not because it's incomplete, but because that's not a modularization question. It's a capacity-planning question, and capacity planning is a separate engineering discipline with its own methods: load modeling, benchmarking, queuing analysis, back-of-envelope arithmetic against hardware specs.

So where does a number like "four servers" come from? From that capacity calculation, done entirely outside the principle. You measure or estimate per-request cost on hardware X, you multiply by concurrency, you apply a safety margin, you get a count. Maybe it's four. Maybe it's fourteen. The principle doesn't care and couldn't produce the number if it tried.

But now something important happens, and this is where the principle re-enters. The capacity calculation has produced knowledge about the system — structural knowledge, not just a number. You now know:

A single instance cannot handle the required load.
The workload must be distributable across multiple instances running in parallel.
Distribution requires elements that didn't previously exist: a way to route requests across instances, a way to share or partition state, a way to coordinate on things that can't be freely replicated, a way to detect and recover from instance failure.

Those "requires" introduce new elements into the system. A load balancer. A session store or sticky-routing scheme. A distributed lock or a partition-key strategy. A health-check mechanism. A failure handler. None of these existed in the pre-analysis system. They exist now because the capacity knowledge forced them into existence.

And here's the key point: each of those new elements carries its own driver set, and those drivers are typically distinct from the drivers of the business logic they serve. They're genuinely new drivers, brought into the system by the structural decisions the capacity analysis forced.

The load balancer's drivers are the routing strategy, the health-check protocol, the traffic patterns it has to handle. They are not the business rules of the requests passing through it.
The session store's drivers are the consistency model, the eviction policy, the replication strategy. They are not the domain rules that produced the sessions.
The partition-key strategy's drivers are the skew characteristics of the key space and the rebalancing cost. They are not the semantics of the partitioned entities.

Once these elements are added to the system, the principle does its usual work over the enlarged element set. Functional elements group with functional elements that share their functional drivers. Infrastructure elements group with infrastructure elements that share their drivers. Where a functional element genuinely participates in an infrastructure driver — say, a business rule whose modification is itself triggered by scaling constraints because it encodes a degradation policy — the principle correctly groups it with the infrastructure cluster rather than its original functional one. The partition is recomputed over a richer set of inputs, and the result is a different modularization than functional drivers alone would give.

Concretely, the resulting cells look something like this:

Cell	Representative drivers	Operational compatibility with other cells
App logic	Domain rules, business workflows, validation logic	Compatible with replication; not compatible with sharing a process with the load balancer (cyclic)
Load balancing	Routing strategy, health-check protocol, traffic patterns	Cannot live inside an instance it balances
Session / state coordination	Consistency model, eviction policy, replication strategy	Must outlive any single instance — independent failure domain
Failure detection	Health-check semantics, timeout policies, recovery rules	Must survive failures of what it monitors

The interesting move happens in the right column. Each cell has, in addition to its driver set, an operational profile: a set of facts about whether the drivers in the cell can be served by sharing a process with another cell. The load balancer cell can't share a process with the app logic cell it balances, because a load balancer running inside one of the app instances can't distribute requests across the four of them — the routing driver becomes unactionable. The session coordination cell can't share a process with any single app instance, because the consistency-and-replication driver requires it to outlive that instance. These aren't claims IVP itself derives. They're engineering facts about runtimes — what a process is, what it means for one process to fail, how routing works. The principle determines that the cells exist as distinct modules; the operational facts determine that some of those modules cannot be realized in-process and must be separate deployable units.

The app logic cell, now freed from the concurrency and routing concerns that have been factored into their own modules, becomes replicable precisely because the concerns that would have prevented replication are no longer tangled into it.

The chain, in order:

Capacity math (outside the principle): 10,000 users on hardware X cannot be served by a single instance.
Element addition (outside the principle, prompted by step 1): the system must now contain load balancing, state coordination, failure detection, and whatever else horizontal scaling requires.
Driver attribution (outside the principle, requires engineering judgment): each new element's drivers are identified — routing drivers for the balancer, consistency drivers for the store, health drivers for the detector.
Repartition (this is the principle's job): the enlarged element set and enlarged driver set are fed in; the principle produces a new partition separating business logic from infrastructure, routing from state, health checking from everything else. The realization of each cell isn't a later decision — it's the operational consequence of which drivers ended up in the cell, evaluated against the engineering facts about how those drivers can actually be served. Cells whose drivers can't all be served at once inside a shared process need to be separate deployable units, and that follows from step 4 directly.
Deployment topology (outside the principle, back to capacity math): the separate deployable unit for app logic runs on four instances, because that's what the original capacity analysis said.

Steps 1, 2, 3, and 5 are performance engineering and architectural judgment. The principle has no access to any of them. Step 4 follows deterministically once the elements, the driver attributions, and the engineering facts about which drivers can coexist in a shared process are all in place. The principle does the partition work; the engineering facts decide which cells can be in-process and which can't.

Two distinct kinds of knowledge

Notice that "there must be a separate service deployed onto four servers" is actually two different claims fused into one sentence, and they enter the principle through different doors.

"There must be a separate service" is a structural claim about elements and drivers. It says: there exist elements whose drivers (combined with engineering facts about runtimes) cannot all be served inside a shared process — they need independent deployment, independent scaling, or an independent failure domain. Once you know that, the principle takes over and propagates the structural consequence: those elements form a cell whose realization is a separate deployable unit. The principle doesn't discover the underlying drivers, but it consumes them and propagates their implications through the partition.

"Deployed onto four servers" is a quantitative fact about capacity and resource allocation. It is not a structural claim about modularization at all. The principle has nothing to say about whether the number is four, forty, or four hundred. You can change the number tomorrow without touching a single module boundary — you adjust a deployment config, you don't re-modularize. But you can't quietly change "separate service" to "in-process library" without reshaping the partition, because the drivers that put it in its own cell haven't gone away.

So the key knowledge, from the principle's point of view, is the structural knowledge. The quantitative part is what made the structural knowledge visible in the first place — capacity math is what revealed that horizontal scaling was necessary — but once the structural fact is established, the specific instance count drops out of the modularization question entirely. If a genie whispered "this system will need to run horizontally scaled" without telling you the number, the principle could already produce the correct partition. If the same genie whispered "this system will need four servers" without telling you why, the principle couldn't do anything with the information — it has no slot for a raw count.

This is the layering the honest answer requires. Capacity math produces numbers and reveals structural necessities. The principle consumes the structural necessities and produces the partition. Operations consumes the partition and the original numbers to decide how many instances of each module run where. Each layer does its own job. When a single mental model tries to carry all three at once, the layers blur, and that blurring is where a lot of microservice sizing confusion comes from.

What the three questions are compressing

The reason Crickett's three questions work is that they compress, in a form practitioners can carry into a meeting, the structural reasoning the principle does formally. That kind of compression is valuable in its own right — in fact it's what good practitioner writing does, and it's what most academic writing fails at. The three questions don't try to do what IVP does; they're a different artifact aimed at a different job. They're the question you ask in the hallway. IVP is what you reach for when the hallway question produces a disagreement neither of you can resolve.

Read this article's argument as unpacking the compression rather than replacing the questions. The reason all three "collapse into one" isn't that the original three are redundant — it's that they're three useful angles on a single underlying question that, viewed structurally, has one shape. Ferguson's three questions before you speak presumably unpack into a single underlying question too: should I say this? That doesn't make Ferguson's three-part formulation useless; it makes it a compression worth understanding.

What the formal lens adds, beyond the compression, is a way to make the question precise enough to settle disagreements. Two engineers asking "does this need to be its own service?" can give different answers and have no shared ground for resolution. Two engineers asking "does this element's driver set match the driver set of any existing module?" can, in principle, identify exactly where they disagree — which driver one of them is including that the other isn't, or which element they're attributing it to. The classical principles SRP, SoC, and CCP each point at related intuitions and run into the same gap when disagreement arises: their core terms aren't sharp enough to localize where the disagreement actually lives. Parnas was already most of the way there in 1972 with "design decisions likely to change"; what was missing was the formal step from that intuition to driver-set equality as the partition criterion.

The practical takeaway

Next time you face a "should this be a service?" decision, Crickett's three questions are a perfectly good prompt — they'll surface the conversation. When they surface a disagreement that the conversation can't resolve, the underlying structural question they're pointing at is this:

What are the change drivers for the elements I'm considering? Include functional drivers, scaling drivers, reliability drivers, deployment-independence drivers, team-autonomy drivers — anything that can genuinely cause these elements to be modified. Then ask: is there an existing module whose set of change drivers matches this one? If yes, the structural answer is to merge. If no, the structural answer is to separate — and which realization (in-process module, library, separate service) the separated module needs is determined by which drivers are in its cell and how those drivers can actually be served operationally.

Be honest about what you know and don't know. If you can't name the quality drivers for an element, you don't have enough information to decide yet. The principle has no "wait until you know" rule — it just has nothing to evaluate when the inputs aren't there. Going and finding out is the right move. Acting on guesses you haven't surfaced as guesses is the move that goes wrong silently.

A few honest scope notes. This article has been talking about server-side, request/response systems with a horizontal-scaling story. The same principle applies elsewhere — to brownfield migrations, FaaS, batch and streaming systems, regulated environments where compliance imposes its own boundaries — but the inputs (what counts as a driver, how the operational compatibility column gets filled in) shift with the context. In a brownfield migration, the order in which you act on the partition is constrained by data and dependency reality; the principle tells you the target, not the path. In regulated industries, compliance boundaries can force separations that aren't visible from drivers alone — those should be modeled as static constraints on realization, not bolted onto the partition. None of these are refutations; they're places where applying the principle requires specific quality knowledge the article hasn't tried to provide.

That's the picture. Three questions, one underlying criterion, and a reminder that no theory of modularization can substitute for knowing your domain and your quality requirements. The theory gives you a precise question; your expertise gives you the inputs; the answer follows. You need both halves.

References

Loth, Y. (2025). The Independent Variation Principle. Zenodo. https://zenodo.org/records/18024111
Loth Y. (2026). IVP as a Meta-Principle: A Unifying Software Architecture Theory. Zenodo https://zenodo.org/records/18748561

Does Formal IVP Modularization Lead to Speculative Fragmentation?

Yannick Loth — Thu, 02 Apr 2026 18:54:57 +0000

A thoughtful comment on my recent LinkedIn post raised three concerns about the Independent Variation Principle that deserve a serious answer.

The concerns are, in essence: that proactive separation by change driver risks massive over-fragmentation; that the existence of a driver does not entail its activation with relevant probability; and that to eliminate subjectivity, the change driver must become a constant or be determined with high probability.

I take these concerns seriously, because they point to the exact place where IVP must distinguish itself from the Single Responsibility Principle.

If IVP inherits SRP's problems, the formal apparatus adds overhead without benefit.
It does not inherit them, and the reasons are structural.

IVP does not over-fragment

The concern is valid against SRP.
SRP is a separation-only criterion: every new "reason to change" creates another module boundary, with no counterweight.
The more reasons you discover or speculate about, the more you split.
Over-fragmentation is a real and well-documented consequence of strict SRP application.

IVP does not work this way.
It has four axioms, and two are directly relevant here.
IVP-3 separates elements with different change driver assignments into different modules.
IVP-4 unifies elements with the same change driver assignment into the same module.
The result is a partition: exactly as many modules as there are distinct driver sets, no more, no fewer.
Over-fragmentation in the structural sense --- splitting co-varying elements across separate modules --- is ruled out by IVP-4, which forces co-varying elements back together.

SRP operates at the class level, where no unification counterpart exists.
Martin's Common Closure Principle (CCP) addresses unification at the package level, but it is a separate principle operating at a different granularity, with the same definitional problem: "change for the same reason" is as undefined as SRP's "reason to change."

IVP provides both separation and unification at any granularity, with a single formal criterion.
That is why strict SRP application tends toward class explosion, while IVP's partition constraint structurally prevents it.

What about speculative drivers --- drivers that might emerge in the future but have no current evidence?
IVP's answer is not "separate just in case."
It is the opposite.
A speculative driver has no knowledge slice: there is no domain knowledge to embody, because the driver does not yet exist in the system's causal structure.
The distinction is not about likelihood but about current causal existence.

The tax authority is a driver because it currently governs elements in the system --- tax rules are already encoded, and the authority can issue changes that force modifications to those elements, whether or not it does so this year.

A regulation that does not yet exist governs no current elements and therefore has no knowledge slice to separate.

When it comes into existence and begins governing elements, it becomes a driver at that point, and the decomposition is updated accordingly.
Assigning a speculative driver to existing elements introduces spurious inequality in the driver assignments, splitting elements that currently co-vary for no reason.

This decreases the quality of the decomposition.

IVP formally prescribes operating on the current driver structure.
The same logic that motivates YAGNI in feature development applies structurally here: speculative drivers are not merely unnecessary boundaries --- they actively degrade the decomposition by introducing spurious splits.

Drivers are not predictions

A change driver is not a prediction that change will happen.

It is an identification of what could cause change within the system's operational domain --- the causal structure that governs how domain knowledge enters and evolves in the system.

The tax authority exists as a source of potential change whether or not it updates tax rates this year.
A database technology is a separate source of variation from a messaging system whether or not you plan to replace either one.

IVP does not ask "how likely is this change?"
It asks "if this change happened, what would be forced to change with it?"
That is a question about causal propagation structure, not about the likelihood of the triggering event.

A driver that rarely activates does not make its boundary wasteful.
All module boundaries carry some fixed cost --- cognitive overhead, interface ceremony, build structure --- but the cost of maintaining a correct boundary for a dormant driver is small and predictable.

The cost of not having the boundary when the driver activates is large and unpredictable: the change propagates through a structure that never accounted for the variation, touching modules that have no reason to be involved.

The alternative --- merging modules because "it probably won't change" --- saves little in the meantime and pays the full propagation cost when it does.

IVP makes subjectivity empirical

This concern rests on the assumption that identifying change drivers introduces a new subjectivity problem.

In practice, every modularization approach already demands the same kind of cognitive work --- understanding what varies independently of what.

Where they differ is in what they do with that understanding.

SRP asks practitioners to identify "reasons to change."
Separation of Concerns asks for "concerns."
DDD asks for "bounded contexts."

If we read port-and-adapter boundaries in Clean Architecture and Hexagonal Architecture as implicitly demarcating sources of independent variation, then these architectural styles, too, involve judgments about what varies independently of what.

Each of these frameworks provides useful heuristics, and experienced practitioners apply them with real skill.

But in each case, the boundary criterion is fuzzy: SRP's "reason to change" is undefined, DDD's bounded context boundary is diagnosed by observing where the ubiquitous language breaks down --- a real signal, but not one that resolves competing boundary placements --- and Clean Architecture's Dependency Rule governs dependency direction but offers no criterion for deciding which layer a given element belongs to in the first place.

The difference is what IVP provides in return.
IVP offers a formal independence test: can this source of change activate without forcing changes to elements governed by that other source?

That test shifts disagreements from irresolvable differences of classification ("is this one responsibility or two?") to concrete, falsifiable factual questions ("does a GDPR change force a SOX change in this system?").

The question can be answered by tracing regulatory dependencies and data flows in the domain --- it does not require predicting whether GDPR will actually change.

Two architects may still reach different answers based on different experience with the domain.
But the nature of their disagreement changes: it becomes empirical rather than classificatory, and it can be investigated by examining domain evidence rather than settled by argument from authority.

Change drivers do not need to be constants.
They do not need high-probability activation.
They need to be causally identifiable --- which, for infrastructure drivers, they generally are, and for business domain drivers, they are through the same counterfactual reasoning and domain analysis that architects already perform.

Where to go from here

The full formal treatment is developed in Volume 1 of the IVP book series (forthcoming).

One Principle, One Proof: Why IVP-Compliant Modules Minimize Change Impact

Yannick Loth — Tue, 10 Mar 2026 09:15:53 +0000

You refactor authentication.
You touch UserController, LoginService, SessionManager, and APIGateway.

Four files for one concern.
You already know this is wrong — but can you prove it?

This article takes a single, universally understood quality metric — change impact — and proves that applying the Independent Variation Principle (IVP) reduces it to the theoretical minimum.
No hand-waving.
No "it depends."
A clean, short proof.

The metric: Change Impact

Every developer intuitively tracks change impact: how many modules do I have to touch when a requirement changes?

Let's make it precise.

A change driver is a single axis of anticipated change — a requirement, a business rule, a technology decision — that, when it changes, forces modifications to the code.
We write γ for a driver.

Change impact counts the modules affected when driver γ activates:

impact(γ, M) = |{ M ∈ M : γ ∈ Γ(M) }|

where Γ(M) is the set of drivers whose elements live in module M.

This is the simplest quality metric you can write down, and arguably the one developers feel most viscerally.
When impact = 1, a change to one concern touches one module.
When impact = 4, you're hunting through four files, coordinating four PRs, risking four merge conflicts.

The principle: IVP in two directives

The Independent Variation Principle has several directives, but only two matter for this proof:

IVP-3 (Separation): Every module contains elements with the same driver assignment.
No module mixes concerns from unrelated drivers.

IVP-4 (Unification): All elements sharing the same driver assignment live in one module.
No driver is scattered across multiple modules.

Under the assumption that every element has exactly one driver (the "pure elements" condition — realistic for well-factored code), these two directives fully determine the modular structure: one module per driver, each module containing exactly the elements governed by that driver.

The proof

Claim: For an IVP-compliant modularization with pure elements, impact(γ, M_IVP) = 1 for every driver γ.
Moreover, IVP-4 is necessary and sufficient for achieving this.

Proof (⇒ IVP achieves impact 1):

By IVP-4, all elements with driver assignment {γ} reside in a single module M_γ.
So the set of modules containing γ is just {M_γ}, and:

impact(γ, M_IVP) = |{M_γ}| = 1

That's it for the forward direction.
One directive, one line of algebra.

Proof (⇐ IVP-4 is necessary):

Suppose IVP-4 is violated: the elements of some driver γ are split across modules M_a and M_b (at least).
Then both M_a and M_b contain elements governed by γ, so:

impact(γ, M') ≥ 2

Any violation of IVP-4 strictly increases change impact for the scattered driver. ∎

What about IVP-3?

IVP-3 (separation) prevents mixing drivers in a single module, but it doesn't affect per-driver impact.

Consider a module that consolidates authentication and payment logic.
If all authentication elements are still in that one module, then impact(γ_auth) = 1 — it's just that the same module also changes when payment logic changes.

IVP-3 violations don't increase change impact per driver.
They increase something else: how often a module is disturbed.
A module hosting 5 drivers changes whenever any of them activates — but that cost shows up in other metrics (cognitive load, test surface), not in per-driver impact.

This is why the proof is clean: change impact depends only on IVP-4.

The concrete example

Step 1: Identify the change driver

Let γ_auth be the authentication change driver.
It activates when any authentication-related requirement changes: password policy, MFA rules, token expiration strategy, or session validation logic.

The elements governed by γ_auth are:

validatePassword — enforces password policy
checkMFA — applies multi-factor rules
expireToken — controls session lifetime based on auth parameters
validateToken — verifies tokens against the auth scheme

All four elements exist because of authentication requirements, and all four must change together when those requirements change.
That's what makes them a single driver: they share the same reason to change.

Step 2: Non-IVP design — scattering γ_auth

A typical layered architecture distributes these elements by technical role rather than by driver:

// UserController.java — handles HTTP input
class UserController {
    void validatePassword(String pwd) {
        if (pwd.length() < 8) throw new ValidationException();
    }
}

// LoginService.java — orchestrates login flow
class LoginService {
    boolean checkMFA(User user) {
        return mfaRequired(user) && passwordStrong(user);
        //                          ^^^^^^^^^^^^^^^^
        // Duplicates password-strength knowledge from UserController.
        // When policy changes, this must change too.
    }
}

// SessionManager.java — manages sessions
class SessionManager {
    void expireToken(String token) {
        long ttl = computeTTL(getPasswordHash(token));
        //         ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        // TTL derivation depends on the password hashing scheme.
        // When the auth scheme changes, this formula changes.
        store.expire(token, ttl);
    }
}

// APIGateway.java — validates incoming requests
class APIGateway {
    boolean validateToken(Request req) {
        return sessionManager.isValid(req.getToken());
        //     ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
        // Calls into SessionManager, which encodes auth assumptions.
        // When token format or validation rules change, this
        // call chain must be re-verified.
    }
}

Driver analysis: γ_auth's elements are scattered across 4 modules.
Each module contains some authentication logic alongside other concerns.

Change scenario: Increase minimum password length from 8 to 12, and switch from bcrypt to argon2.

What changes:

UserController — the length check (< 8 → < 12)
LoginService — passwordStrong() encodes strength criteria that just changed
SessionManager — computeTTL(getPasswordHash(...)) depends on the hashing scheme, which just changed from bcrypt to argon2
APIGateway — token validation indirectly depends on the new session format; integration tests break, call chain needs re-verification

impact(γ_auth, M') = 4. Four modules, four PRs, four risk surfaces.

Why this is non-IVP: IVP-4 requires all elements with the same driver assignment to live in one module.
Here, the four γ_auth elements live in four different modules.
IVP-4 is violated.

Step 3: IVP-compliant design — unifying γ_auth

Group all elements governed by γ_auth into a single module:

// AuthenticationService.java — ALL γ_auth elements here
class AuthenticationService implements IAuthProvider {
    void validatePassword(String pwd) {
        if (pwd.length() < 8) throw new ValidationException();
    }
    boolean checkMFA(User user)      { /* MFA rules here     */ }
    void expireToken(String token)   { /* expiry logic here  */ }
    boolean validateToken(Request r) { /* validation here    */ }
}

// IAuthProvider.java — stable interface (not governed by γ_auth)
interface IAuthProvider {
    boolean authenticate(Credentials c);
    boolean validateSession(String token);
}
// UserController, LoginService, SessionManager, APIGateway
// all depend on IAuthProvider — never on auth internals.

Driver analysis: Every element governed by γ_auth lives in AuthenticationService.
No other module contains authentication logic — they call through IAuthProvider, whose signature is stable across auth changes.

Same change scenario: Increase password length, switch hashing scheme.

What changes: AuthenticationService. Nothing else.
The interface IAuthProvider doesn't change (it exposes authenticate and validateSession, not password-length constants or hashing algorithms).
Callers are untouched.

impact(γ_auth, M_IVP) = 1.

Why this is IVP-compliant:

IVP-4 (unification): All γ_auth elements are in one module. ✓
IVP-3 (separation): AuthenticationService contains only γ_auth elements — no payment logic, no user profile logic. ✓

Why this matters more than you think

Change impact = 1 is not just "nice to have."
It is the theoretical minimum — you cannot do better than touching one module for a single-driver change (someone has to implement the change).

And the proof tells you something stronger: IVP-4 is not just sufficient for achieving this minimum, it is necessary.
There is no alternative modularization strategy that achieves universal impact = 1 without satisfying IVP-4.

This means every time you scatter a concern across modules — whether through "convenience," layered architecture conventions, or framework-imposed structure — you are provably increasing change impact.
Not probably. Not usually. Provably.

The meta-theorem (a teaser)

Change impact is just one metric.
In the book I'm currently writing, I prove a Quality Meta-Theorem showing that IVP simultaneously minimizes an entire family of quality metrics — change impact, cognitive load, test surface, defect localization scope — through a single structural argument.

The key insight: all these metrics can be expressed as functions of two module-level quantities:

Driver count per module (|Γ(M)|) — minimized to 1 by IVP-3 and IVP-4 together (separation prevents mixing; unification ensures one module per driver)
External dependency count (|D_ext(M)|) — minimized to the causal lower bound by IVP-4 (unification internalizes all same-driver dependencies)

Any metric that (a) decomposes as a sum over modules, (b) depends only on these two quantities per module, (c) is monotone in both, and (d) satisfies a superadditivity condition, is provably minimized by IVP.
The theorem calls such metrics driver-decomposable.
Change impact, cognitive load, test surface, and defect localization scope all qualify.

Change impact is the simplest member of this family.
It won't be the last one you care about.

References

Loth, Y. (2025). The Independent Variation Principle (IVP). Zenodo. https://zenodo.org/records/18024111
Loth, Y. (2026). Book to be published (Volume 1). Chapter 9: Quality Metrics Under IVP.

DEV Community: Yannick Loth

On the Nature of Cohesion

SRP's Vocabulary Problem: Why Every Reformulation Failed

SRP Is Wrong: The Cardinality Error in the Single Responsibility Principle

SOLID Heuristics Reveal Incomplete Domain Knowledge — Nothing More

How each case is presented

The Independent Variation Principle

SRP: Bundled Causal Concerns

Knowledge with the gap

Knowledge without the gap

IVP application

Accidental coupling: with the gap vs. without

When SRP is wrong

OCP: Failure to Anticipate Driver-Independent Variation

Knowledge with the gap

Knowledge without the gap

IVP application

Accidental coupling: with the gap vs. without

LSP: Structural Placement First, Behavioral Validity Second

Knowledge with the gap

Knowledge without the gap

IVP application

When LSP is not a knowledge gap

Accidental coupling: with the gap vs. without

ISP: Conflated Client Contracts

Knowledge with the gap

Knowledge without the gap

IVP application

Accidental coupling: with the gap vs. without

DIP: Bundled Abstraction and Implementation

Knowledge with the gap

Knowledge without the gap

IVP application

Accidental coupling: with the gap vs. without

The Synthesis

What This Means

A note on Robert C. Martin's achievement

Further Reading

References

Where Do Interfaces Live? IVP Answers What SOLID Cannot

Result 1: DIP → ISP, formalized in IVP terms

Result 2: A unique modularization

What this settles

What IVP's placement produces

The paper

SOLID's Packaging Principles Are Jointly Unsatisfiable

The setup

The result

It gets worse

Every recommendation is self-defeating

Why this matters

The paper

SOLID: ISP Is Just DIP Applied Twice

Process-First Design and the Independent Variation Principle: Two Paths to the Same Territory

The process-first framework

The Independent Variation Principle

Where the two frameworks meet

Where the two frameworks diverge

What the two approaches contribute to each other

Which Java Construct Should You Use? Let Change Drivers Decide

Non-static inner class

Static nested class

Lambda

Method reference

Anonymous class

Record

Sealed interface with pattern matching

Optional and Result

Enum

The direction of Java's evolution

The decision

Three Questions Before You Add a Microservice — and Why They All Collapse Into One

The criterion: same drivers together, different drivers apart

Question 2 first, because it's the cleanest

Question 3: the temporal illusion

Question 1: the technology trap

One question, not three

But here's the catch

A worked example: 10,000 users and four servers

Two distinct kinds of knowledge