solid-ddd（固体 ddd）

solid-ddd

Language-agnostic catalog of SOLID design principles and Domain-Driven Design tactical patterns with concrete do/don't examples.

Triggers: Always loaded for non-documentation code changes. Load when writing or reviewing any class, module, domain object, service, or repository. Applicable across all languages and frameworks.

Patterns

SOLID Principles

SRP — Single Responsibility Principle

A class, module, or function has exactly one reason to change. One unit = one concern.

DON'T — one class handles both order persistence and email notification:

// [Illustrative — TypeScript]
class OrderService {
  save(order: Order): void { /* writes to DB */ }
  sendConfirmationEmail(order: Order): void { /* sends email */ }
  calculateDiscount(order: Order): number { /* discount logic */ }
}

DO — each class owns one responsibility:

// [Illustrative — TypeScript]
class OrderRepository { save(order: Order): void { /* DB only */ } }
class OrderNotifier { sendConfirmation(order: Order): void { /* email only */ } }
class DiscountCalculator { calculate(order: Order): number { /* pricing only */ } }

Signal — SRP violated: the class has multiple unrelated reasons to change (schema change AND email template change affect the same file).

OCP — Open/Closed Principle

A unit is open for extension, closed for modification. Add behavior by adding code, not by editing existing code.

DON'T — every new payment method requires editing the same function:

// [Illustrative — TypeScript]
function processPayment(type: string, amount: number) {
  if (type === 'credit') { /* ... */ }
  else if (type === 'paypal') { /* ... */ }
  // Adding 'crypto' forces editing this function
}

DO — new behavior is added by adding a new implementation:

// [Illustrative — TypeScript]
interface PaymentProcessor { process(amount: number): void; }
class CreditProcessor implements PaymentProcessor { process(amount) { /* ... */ } }
class PaypalProcessor implements PaymentProcessor { process(amount) { /* ... */ } }
// Adding crypto: create CryptoProcessor — no existing code touched

Signal — OCP violated: adding a new variant requires touching a central switch/if chain that already exists.

LSP — Liskov Substitution Principle

Subtypes must be substitutable for their base types without altering correctness. A subclass must honor the contract of its parent.

DON'T — subclass breaks the parent contract by throwing where parent succeeds:

// [Illustrative — TypeScript]
class Rectangle { setWidth(w: number) { this.width = w; } }
class Square extends Rectangle {
  setWidth(w: number) { this.width = w; this.height = w; } // Breaks area contract
}

DO — prefer composition or a shared interface with separate implementations:

// [Illustrative — TypeScript]
interface Shape { area(): number; }
class Rectangle implements Shape { area() { return this.width * this.height; } }
class Square implements Shape { area() { return this.side * this.side; } }

Signal — LSP violated: calling code needs to check the concrete type before using the abstraction (if (shape instanceof Square)).

ISP — Interface Segregation Principle

Clients must not be forced to depend on methods they do not use. Prefer narrow, focused interfaces over fat ones.

DON'T — one fat interface forces every implementor to stub unused methods:

// [Illustrative — TypeScript]
interface Worker {
  work(): void;
  eat(): void;   // Robots don't eat
  sleep(): void; // Robots don't sleep
}
class RobotWorker implements Worker {
  work() { /* real logic */ }
  eat() { throw new Error('Not supported'); }   // forced no-op
  sleep() { throw new Error('Not supported'); } // forced no-op
}

DO — split into narrow interfaces; each class implements only what it needs:

// [Illustrative — TypeScript]
interface Workable { work(): void; }
interface Feedable { eat(): void; sleep(): void; }
class HumanWorker implements Workable, Feedable { /* all methods real */ }
class RobotWorker implements Workable { work() { /* only real method */ } }

Signal — ISP violated: an implementor has one or more methods that throw NotImplementedException, return empty, or are no-ops.

DIP — Dependency Inversion Principle

High-level modules must not depend on low-level modules. Both depend on abstractions. Abstractions must not depend on details.

DON'T — high-level service directly instantiates a concrete repository:

// [Illustrative — TypeScript]
class OrderService {
  private repo = new PostgresOrderRepository(); // concrete dependency
  placeOrder(order: Order) { this.repo.save(order); }
}

DO — high-level service depends on an abstraction; the concrete class is injected:

// [Illustrative — TypeScript]
interface OrderRepository { save(order: Order): void; }
class OrderService {
  constructor(private repo: OrderRepository) {} // depends on abstraction
  placeOrder(order: Order) { this.repo.save(order); }
}
// Caller injects: new OrderService(new PostgresOrderRepository())

Signal — DIP violated: new ConcreteClass() inside a service constructor or method body with no injection seam.

DDD Tactical Patterns

Entity

An object defined by its identity, not its attributes. Two entities with the same ID are the same entity even if their data differs.

• Has: a stable, unique identifier (ID) that persists across state changes.
• Behavior: encapsulates domain logic relevant to its lifecycle.
• Distinguishing signal vs. Value Object: ask "does it matter which one it is?" — if yes, it is an Entity.

// [Pseudocode]
Entity Order { id: OrderId; status: OrderStatus; items: Item[] }
// Two Orders with id=42 are the same order even if status changed

Value Object

An object defined entirely by its attributes. No identity. Immutable. Equality is structural.

• Has: no ID field. Equality is based on all attribute values.
• Immutable: replace, never mutate. Operations return new instances.
• Distinguishing signal vs. Entity: ask "does it matter which one it is?" — if no, it is a Value Object.

// [Pseudocode]
ValueObject Money { amount: Decimal; currency: Currency }
// Money(10, USD) == Money(10, USD) — two instances are equal by value

Aggregate

A cluster of domain objects (one Entity as root + optional child objects) treated as a single unit for data changes. All access to internal objects goes through the Aggregate Root.

• Aggregate Root is the only public entry point. External code holds a reference only to the root.
• Invariants that span multiple child objects are enforced by the root.
• Transactions should not span multiple Aggregates — each Aggregate is a consistency boundary.

// [Pseudocode]
Aggregate Order (root) {
  addItem(product, qty) // enforces max-items invariant
  removeItem(itemId)
  confirm()             // guards: status must be DRAFT
}
// External code: order.addItem(…) — never order.items.push(…) directly

Repository

An abstraction that provides collection-like access to Aggregates. Hides the persistence mechanism from the domain layer.

• Interface lives in the domain layer. Implementation lives in the infrastructure layer (DIP applied).
• Methods are domain-language methods (findById, findByCustomer, save) — not SQL or ORM calls.
• One Repository per Aggregate Root — not per entity or table.

// [Pseudocode]
interface OrderRepository {
  findById(id: OrderId): Order | null
  findByCustomer(customerId: CustomerId): Order[]
  save(order: Order): void
}

Domain Service

A stateless operation that belongs to the domain but does not naturally fit inside a single Entity or Value Object.

• Stateless: no mutable fields; takes input, returns output or raises domain events.
• Belongs in the domain layer: contains business rules, not application orchestration.
• Use when: the operation involves multiple Aggregates or the logic does not belong to any single object.

// [Pseudocode]
DomainService TransferService {
  transfer(from: Account, to: Account, amount: Money): void {
    from.debit(amount)
    to.credit(amount)
    // Invariant: total money in system unchanged
  }
}

Application Service

Orchestrates domain objects and services to fulfill a single use case. Lives in the application layer, not the domain layer.

• Thin: no business logic — only coordination (load, call domain, save, emit events).
• Transaction boundary: one use case = one transaction (typically).
• Calls domain services and repositories — never bypasses the domain to manipulate entities directly.

// [Pseudocode]
ApplicationService PlaceOrderUseCase {
  execute(cmd: PlaceOrderCommand): OrderId {
    customer = customerRepo.findById(cmd.customerId)
    order = Order.create(customer, cmd.items)   // domain logic in Order
    orderRepo.save(order)
    eventBus.publish(order.domainEvents())
    return order.id
  }
}

Domain Event

A record that something meaningful happened in the domain. Published by Aggregates; consumed by other parts of the system.

• Immutable: represents a past fact — never modified after creation.
• Named in past tense: OrderPlaced, PaymentReceived, InventoryDepleted.
• Carries only what happened: not a command, not a query — a fact with a timestamp and relevant data.

// [Pseudocode]
DomainEvent OrderPlaced {
  orderId: OrderId
  customerId: CustomerId
  occurredAt: Timestamp
}

Anti-Patterns

God Class

What it is: one class that accumulates responsibilities across multiple unrelated concerns — persistence, business rules, HTTP handling, formatting, notification, etc.

Detection signals:

• Class has > 10 public methods spanning unrelated concerns.
• Multiple unrelated reasons to change (DB schema change AND email template change both affect this class).
• Class name ends in Manager, Handler, Processor, or Helper and does everything.

Why it is a problem: violates SRP. Any change risks breaking unrelated functionality. Testing requires setting up the entire class even for a small feature.

Corrective direction: identify distinct responsibilities, extract each into a focused class. Apply the "one reason to change" test to each extract.

Anemic Domain Model

What it is: domain objects (entities, aggregates) are pure data containers — they have fields and getters/setters but no behavior. All business logic lives in service classes.

Detection signals:

• Entity classes contain only fields, constructors, and getters/setters.
• Service classes contain all conditionals, calculations, and state transitions that relate to entity data.
• To understand business rules you must read the service, not the entity.

Why it is a problem: violates DDD. Domain logic leaks into the application layer, becomes scattered across services, and is hard to find, test, or enforce as invariants.

Corrective direction: move business behavior (state transitions, invariant enforcement, calculations) into the entity or value object that owns the data.

Service as God Object

What it is: a single application service (or domain service) that directly orchestrates all domain logic with no delegation — it reads entities, applies all business rules inline, and writes results.

Detection signals:

• Service method is > 50 lines of business logic with no calls to domain object methods.
• Service knows the internal structure of multiple unrelated aggregates.
• Removing one service method would break unrelated features.

Why it is a problem: combines the God Class problem with the Anemic Domain Model — SRP is violated at the service level, and domain objects remain empty data bags.

Corrective direction: delegate business logic to domain objects and domain services. The application service should orchestrate (load → call domain → persist → publish) without containing rules itself.

Rules

• Apply SRP before adding a second responsibility to any class, module, or function — extract first, then implement.
• Apply DIP at every layer boundary: domain → infrastructure, application → domain. Never instantiate a concrete dependency inside a high-level class.
• Value Objects MUST be immutable. Mutation returns a new instance; it never modifies this.
• Aggregate Roots are the sole entry points for state changes on their cluster. No direct mutation of child objects from outside the Aggregate.
• Repositories are defined as interfaces in the domain layer. Concrete implementations belong in the infrastructure layer.
• Application Services MUST be thin orchestrators. Business logic inside an Application Service is a violation — move it to the domain object or Domain Service.
• Domain Events MUST be named in past tense and treated as immutable facts.
• Code examples in this skill are illustrative only (labeled with language). They are not production templates.