Core Design Principles — Deep Dive

Level: Beginner → Intermediate
Pre-reading: 01 · Architectural Foundations

Why Principles Matter

Patterns solve specific problems. Principles guide decision-making when no pattern fits exactly. They're the "first principles" you reason from when facing unfamiliar situations.

Loose Coupling

"Components should depend on each other as little as possible."

Coupling measures how much one component knows about another's internal workings.

Coupling Spectrum

graph LR
    A[Shared DB] --> B[RPC/REST]
    B --> C[Events]
    C --> D[No Dependency]
    style A fill:#f99
    style B fill:#ff9
    style C fill:#9f9
    style D fill:#9ff

How to Achieve Loose Coupling

High Cohesion

"Related code should live together; unrelated code should live apart."

Cohesion measures how focused a component is. High cohesion means everything in the component serves a single, well-defined purpose.

Cohesion and Service Boundaries

graph TD
    subgraph High Cohesion
        A[Order Service] --> B[Create Order]
        A --> C[Cancel Order]
        A --> D[Order Status]
    end
    subgraph Low Cohesion
        E[Business Service] --> F[Create Order]
        E --> G[Update Inventory]
        E --> H[Send Email]
        E --> I[Calculate Tax]
    end

Testing Cohesion

Design for Failure

"In distributed systems, failure is not an exception — it's the norm."

Every network call can fail. Every service can go down. Every database can timeout. Design assuming everything will fail.

Failure Modes

Design Patterns for Failure

→ Deep Dive: Resilience Patterns for implementation details

Single Responsibility Principle (SRP)

"A component should have one, and only one, reason to change."

"Reason to change" = a stakeholder or business capability. If a change to billing logic and a change to shipping logic both require modifying the same service, that service has too many responsibilities.

At the Service Level

At the Code Level

Fail Fast

"Surface problems immediately; don't hide or swallow errors."

The longer an error goes undetected, the harder it is to diagnose and the wider the blast radius.

Implementation

// Fail fast: validate at entry point
public Order createOrder(OrderRequest request) {
    Objects.requireNonNull(request, "Request cannot be null");
    if (request.getItems().isEmpty()) {
        throw new IllegalArgumentException("Order must have items");
    }
    // Proceed with valid request
}

# Kubernetes: fail fast startup probe
startupProbe:
  httpGet:
    path: /actuator/health
    port: 8080
  failureThreshold: 3
  periodSeconds: 5

Immutable Infrastructure

"Don't patch production — replace it."

Mutable infrastructure: SSH into servers, apply patches, modify config files. State drifts; "works on my machine" multiplies.

Immutable infrastructure: Build new images with changes; deploy them; destroy old instances. Every deployment is a fresh start.

Benefits

Everything as Code

"If it's not in Git, it doesn't exist."

Version control isn't just for application code. Infrastructure, configuration, pipelines, policies — all should be codified, reviewed, and versioned.

Benefits

Separation of Concerns

"Each component should handle one aspect of functionality."

Related to SRP but at a higher level. Different types of concerns should be separated:

Cross-Cutting Concerns

Some concerns span all components: logging, security, metrics. Handle them consistently without duplicating logic:

Principle Tensions

Principles sometimes conflict. Architecture is about navigating trade-offs:

Principle Checklist

Use this when reviewing designs:

• [ ] Can this component change independently of others?
• [ ] Does this component do one thing well?
• [ ] What happens when this dependency fails?
• [ ] Is there a single reason this code would change?
• [ ] Would a bug here be detected immediately?
• [ ] Is the infrastructure reproducible from scratch?
• [ ] Is everything needed to deploy this system in version control?
• [ ] Is business logic separate from infrastructure concerns?