Software Architecture Principles

Separation of Concerns · High Cohesion · Loose Coupling — the three principles that decide whether a system stays changeable after year three.

1. Separation of Concerns (SoC)

Definition. SoC is the practice of dividing a system into parts that each address a distinct concern, so that a decision about one concern can be made without knowing the details of the others. A "concern" is any coherent set of responsibilities that can change for its own reasons: persistence, transport, business rules, presentation, authentication, observability, configuration.

SoC is the oldest of the three — Dijkstra described it in 1974 as "the only available technique for effective ordering of one's thoughts" — and it is the reason layered, hexagonal and clean architectures exist at all. The other two principles are what you measure after you have separated concerns: cohesion tells you whether you cut in the right place, coupling tells you whether the cut actually isolates change.

Where the boundaries usually go

Violation, then repair

// ---- BAD: one function owns transport, rules, persistence and presentation ----
async function checkout(req, res) {
  const cart = JSON.parse(req.body);                              // transport
  if (cart.items.length === 0) return res.status(400).send('empty'); // rules + transport
  let total = cart.items.reduce((s, i) => s + i.price * i.qty, 0);
  if (cart.coupon === 'SAVE10') total = total * 0.9;               // rule buried in the controller
  await db.query('INSERT INTO orders (total) VALUES (?)', [total]); // persistence
  res.send('<h1>Thanks! Total ' + total + '</h1>');               // presentation
}

// ---- GOOD: each concern in its own place ----
class Checkout {                       // domain: pure rules, unit-testable without a server
  static total(items, coupon) { /* invariants + pricing */ }
}
class OrderRepository { save(order) {} }               // infrastructure
class CheckoutController {                             // transport only: map in, map out
  constructor(useCase) { this.useCase = useCase; }
  async handle(req, res) {
    const result = await this.useCase.execute(toCommand(req.body));
    res.status(result.ok ? 200 : 422).json(result);
  }
}

2. High Cohesion

Definition. Cohesion measures how strongly related the responsibilities inside a single module are. High cohesion means everything in the module serves one purpose and changes for the same reason. It is the answer to "did I cut the system in the right place?".

The classic seven levels, best to worst:

The "and" test

A cheap, reliable detector: describe what the module does in one sentence. Every "and" in that sentence is a candidate split. Every "or" is a strategy hiding behind a flag.

// ---- BAD: "InvoiceService creates invoices AND renders PDFs AND emails customers" ----
class InvoiceService {
  create() {}
  renderPdf() {}
  sendEmail() {}
}

// ---- GOOD: three modules, three reasons to change ----
class InvoiceService   { create() {} }        // changes when billing rules change
class InvoiceRenderer  { toPdf(invoice) {} }  // changes when the template changes
class InvoiceNotifier  { send(invoice) {} }   // changes when the delivery channel changes

3. Loose Coupling

Definition. Coupling measures how much one module depends on the internal details of another. Loose coupling means a module can be understood, tested, replaced or redeployed without editing its neighbours — interaction happens through a narrow, stable, intention-revealing contract.

Coupling types, from worst to best:

Tight versus loose, same feature

// ---- BAD: the use case is welded to Stripe, to its SDK and to its errors ----
class SubscribeUseCase {
  async run(userId, plan) {
    const stripe = new Stripe(process.env.STRIPE_KEY);
    const sub = await stripe.subscriptions.create({ customer: userId, items: [{ price: plan }] });
    return sub.id;
  }
}

// ---- GOOD: the use case depends on a port it defines itself ----
interface PaymentGateway {                  // the contract belongs to the caller, not the vendor
  charge(customerId: string, amountCents: number): Promise<ChargeId>;
}

class SubscribeUseCase {
  constructor(private readonly payments: PaymentGateway) {}
  async run(customerId: string, amountCents: number) {
    return this.payments.charge(customerId, amountCents);
  }
}

// infrastructure: swap Stripe for Adyen or an in-memory fake without touching the use case
class StripeGateway implements PaymentGateway { /* ... */ }

Techniques that actually reduce coupling

• Depend on abstractions you own. Ports defined by the consumer (hexagonal / dependency inversion) mean vendor SDK types never reach the domain.
• Invert with dependency injection instead of importing a concrete client or a service locator.
• Prefer asynchronous events over synchronous chains when the caller does not need the answer — the publisher then knows only the event schema.
• Share contracts, not models. Publish DTOs and event schemas; never share ORM entities or domain objects across service boundaries.
• Law of Demeter. Talk to your direct collaborator, not to its collaborator's collaborator (a.getB().getC().do() is a coupling chain of length three).
• Depend in the direction of stability. Volatile modules (UI, adapters) depend on stable ones (domain, contracts); never the reverse.
• Keep the boundary narrow. A 40-method interface couples as much as a shared database. Small interfaces, few parameters, explicit types.

4. How the three balance each other

The three principles are one idea seen from three angles: SoC tells you to cut, cohesion tells you whether the cut is coherent, coupling tells you whether the cut insulates change. Optimising only one degrades the others.

5. Measuring them

You do not have to guess. Structural metrics approximate cohesion and coupling well enough to catch regressions in CI:

Tooling that computes these on real code: jdepend and ArchUnit (Java), NetArchTest (·NET), dependency-cruiser and madge (JS/TS), pydeps and import-linter (Python). Architectural tests are the durable form of these principles: encode "domain must not import infrastructure" as an assertion, not as a convention in a wiki.

6. Review checklist

• Every module can be described in one sentence without "and".
• Each module has one identifiable reason to change, and it is written down.
• The domain layer has no framework, I/O, serialization or ORM dependency.
• External systems are reached through ports owned by the consumer, not vendor SDK types.
• No shared mutable global state between modules; state is passed explicitly.
• Cross-boundary data are DTOs or event schemas, never internal entities.
• Dependencies point inward / toward stability; no cycles between packages.
• Swapping a database, a broker or a UI framework would not require editing business rules.
• Each module's tests can run without standing up the whole system.
• Architectural constraints are enforced by automated tests, not by convention.

7. Smells and anti-patterns