tactical-ddd

Compare original and translation side by side

🇺🇸

Original

English
🇨🇳

Translation

Chinese

Tactical DDD

战术DDD

Design, refactor, analyze, and review code by applying the principles and patterns of tactical domain-driven design.
运用战术领域驱动设计的原则和模式来设计、重构、分析和评审代码。

Principles

原则

  1. Isolate domain logic
  2. Use rich domain language
  3. Orchestrate with use cases
  4. Avoid anemic domain model
  5. Separate generic concepts
  6. Make the implicit explicit... like your life depends on it
  7. Design aggregates around invariants
  8. Extract immutable value objects liberally

  1. 隔离领域逻辑
  2. 使用富领域语言
  3. 用用例编排逻辑
  4. 避免贫血领域模型
  5. 分离通用概念
  6. 将隐式概念显式化——就像事关生死一样重视
  7. 围绕不变量设计聚合
  8. 大量提取不可变值对象

1. Isolate domain logic

1. 隔离领域逻辑

What: Domain logic is not mixed with technical code like HTTP and database transactions.
Why: Easier to understand the most important part of the code, easier to validate with domain experts, easier to test and evolve, easier to plan and implement new features.
Test: Could a domain expert read the code? Can the code be unit tested without mocks or spinning up databases?
typescript
// ❌ WRONG - domain polluted with infrastructure
class Delivery {
  async dispatch() {
    this.logger.info('Dispatching delivery', { id: this.id })  // Infrastructure!
    await this.db.beginTransaction()                           // Infrastructure!
    if (this.status !== 'ready') throw new Error('Not ready')
    this.status = 'dispatched'
    await this.db.save(this)                                   // Infrastructure!
    await this.db.commit()                                     // Infrastructure!
    await this.pushNotification.notifyDriver()                 // Infrastructure!
  }
}

// ✅ RIGHT - isolated domain logic
class Delivery {
  dispatch(): void {
    if (this.status !== DeliveryStatus.Ready) {
      throw new DeliveryNotReadyError(this.id)
    }
    this.status = DeliveryStatus.Dispatched
    this.dispatchedAt = new Date()
  }
}

定义: 领域逻辑不与HTTP、数据库事务等技术代码混合。
原因: 便于理解代码中最重要的部分,便于与领域专家验证,便于测试和演进,便于规划和实现新功能。
验证方法: 领域专家能否读懂这段代码?无需模拟对象或启动数据库就能对代码进行单元测试吗?
typescript
// ❌ WRONG - domain polluted with infrastructure
class Delivery {
  async dispatch() {
    this.logger.info('Dispatching delivery', { id: this.id })  // Infrastructure!
    await this.db.beginTransaction()                           // Infrastructure!
    if (this.status !== 'ready') throw new Error('Not ready')
    this.status = 'dispatched'
    await this.db.save(this)                                   // Infrastructure!
    await this.db.commit()                                     // Infrastructure!
    await this.pushNotification.notifyDriver()                 // Infrastructure!
  }
}

// ✅ RIGHT - isolated domain logic
class Delivery {
  dispatch(): void {
    if (this.status !== DeliveryStatus.Ready) {
      throw new DeliveryNotReadyError(this.id)
    }
    this.status = DeliveryStatus.Dispatched
    this.dispatchedAt = new Date()
  }
}

2. Use rich domain language

2. 使用富领域语言

What: Names in code match exactly what domain experts say. No programmer jargon. No generic names.
Why: Translation between code-speak and business-speak causes bugs. When a domain expert says "assess a claim" and the code says "processEntity", someone will misunderstand something.
Test: Would a domain expert recognize this name? If you'd need to translate it for them, it's wrong.
Common generic terms to watch for:
  • Manager
    ,
    Handler
    ,
    Processor
    ,
    Helper
    ,
    Util
  • Data
    ,
    Info
    ,
    Item
    (when domain terms exist)
  • process
    ,
    handle
    ,
    execute
    (what does it actually DO?)
typescript
// ❌ WRONG - programmer jargon
class ClaimHandler {
  processClaimData(claimData: ClaimDTO): ProcessingResult {
    return this.claimProcessor.handle(claimData)
  }
}

// ✅ RIGHT - domain language
class ClaimAssessor {
  assessClaim(claim: InsuranceClaim): AssessmentDecision {
    if (claim.exceedsCoverageLimit()) {
      return AssessmentDecision.deny(DenialReason.ExceedsCoverage)
    }
    return AssessmentDecision.approve()
  }
}

定义: 代码中的命名与领域专家的表述完全一致,避免程序员行话和通用命名。
原因: 代码术语与业务术语之间的转换会导致bug。当领域专家说“评估索赔”而代码里写“processEntity”时,一定会有人产生误解。
验证方法: 领域专家能认出这个命名吗?如果需要为他们翻译,那这个命名就是错误的。
需要注意的常见通用术语:
  • Manager
    ,
    Handler
    ,
    Processor
    ,
    Helper
    ,
    Util
  • Data
    ,
    Info
    ,
    Item
    (当存在领域术语时)
  • process
    ,
    handle
    ,
    execute
    (它实际是做什么的?)
typescript
// ❌ WRONG - programmer jargon
class ClaimHandler {
  processClaimData(claimData: ClaimDTO): ProcessingResult {
    return this.claimProcessor.handle(claimData)
  }
}

// ✅ RIGHT - domain language
class ClaimAssessor {
  assessClaim(claim: InsuranceClaim): AssessmentDecision {
    if (claim.exceedsCoverageLimit()) {
      return AssessmentDecision.deny(DenialReason.ExceedsCoverage)
    }
    return AssessmentDecision.approve()
  }
}

3. Orchestrate with use cases

3. 用用例编排逻辑

What: A use case is a user goal—something a user would recognize as an action they can perform in your application.
Why: Use cases define the entry points to your domain. They answer "what can a user do?" If something isn't a user goal, it's supporting machinery that belongs elsewhere.
Test (the menu test): If you described your application's features to a user like a menu, would this be on it?
DELIVERY APP MENU:
├── Request Delivery     ← Use case: user goal
├── Track Delivery       ← Use case: user goal
├── Cancel Delivery      ← Use case: user goal
├── Calculate ETA        ← NOT a use case: internal machinery
└── Check Delivery Radius ← NOT a use case: domain rule
typescript
// ❌ WRONG - not a user goal, this is internal machinery
// use-cases/calculate-eta.use-case.ts
async function calculateETA(deliveryId: DeliveryId) {
  const delivery = await deliveryRepository.find(deliveryId)
  const driver = await driverRepository.find(delivery.driverId)
  return routeService.estimateArrival(driver.location, delivery.destination)
}

// ✅ RIGHT - actual user goal (appears in menu)
// use-cases/cancel-delivery.use-case.ts
async function cancelDelivery(deliveryId: DeliveryId, reason: CancellationReason) {
  const delivery = await deliveryRepository.find(deliveryId)
  delivery.cancel(reason)
  await deliveryRepository.save(delivery)
}

定义: 用例是用户的目标——即用户在应用中能执行的、可识别的操作。
原因: 用例定义了领域的入口点,回答了“用户能做什么?”如果某件事不是用户目标,那它就是属于其他地方的支撑性机制。
验证方法(菜单测试): 如果你像介绍菜单一样向用户描述应用功能,这个操作会出现在菜单里吗?
配送应用菜单:
├── 发起配送     ← 用例:用户目标
├── 追踪配送       ← 用例:用户目标
├── 取消配送      ← 用例:用户目标
├── 计算预计到达时间        ← 非用例:内部机制
└── 检查配送范围 ← 非用例:领域规则
typescript
// ❌ WRONG - not a user goal, this is internal machinery
// use-cases/calculate-eta.use-case.ts
async function calculateETA(deliveryId: DeliveryId) {
  const delivery = await deliveryRepository.find(deliveryId)
  const driver = await driverRepository.find(delivery.driverId)
  return routeService.estimateArrival(driver.location, delivery.destination)
}

// ✅ RIGHT - actual user goal (appears in menu)
// use-cases/cancel-delivery.use-case.ts
async function cancelDelivery(deliveryId: DeliveryId, reason: CancellationReason) {
  const delivery = await deliveryRepository.find(deliveryId)
  delivery.cancel(reason)
  await deliveryRepository.save(delivery)
}

4. Avoid anemic domain model

4. 避免贫血领域模型

What: Domain logic lives in domain objects, not in use cases. Use cases orchestrate; domain objects decide.
Why: When business rules leak into use cases, they scatter across the codebase, duplicate, and diverge. The domain becomes a dumb data carrier.
Test: Is your use case making business decisions, or just coordinating? If the use case contains if/else business logic, you likely have an anemic model.
typescript
// ❌ WRONG - business logic in use case (anemic domain)
async function confirmDropoff(deliveryId: DeliveryId, photo: ProofPhoto) {
  const delivery = await deliveryRepository.find(deliveryId)

  // Business rules leaked into use case!
  if (delivery.status !== 'in_transit') {
    throw new Error('Delivery not in transit')
  }
  if (!photo && delivery.requiresSignature) {
    throw new Error('Proof of delivery required')
  }

  delivery.status = 'delivered'
  delivery.proofPhoto = photo
  delivery.deliveredAt = new Date()
  await deliveryRepository.save(delivery)
}

// ✅ RIGHT - use case orchestrates, domain decides
async function confirmDropoff(deliveryId: DeliveryId, photo: ProofPhoto) {
  const delivery = await deliveryRepository.find(deliveryId)

  delivery.confirmDropoff(photo)  // Domain enforces the rules

  await deliveryRepository.save(delivery)
}
Signs of anemic model:
  • Use cases full of if/else business logic
  • Domain objects are just data with getters/setters
  • Business rules duplicated across multiple use cases
  • Validation logic outside the object being validated

定义: 领域逻辑存在于领域对象中,而非用例里。用例负责编排,领域对象负责决策。
原因: 当业务规则泄露到用例中时,它们会在代码库中分散、重复并产生分歧,领域会变成一个哑数据载体。
验证方法: 你的用例是在做业务决策,还是仅负责协调?如果用例包含if/else业务逻辑,那么你很可能存在贫血模型。
typescript
// ❌ WRONG - business logic in use case (anemic domain)
async function confirmDropoff(deliveryId: DeliveryId, photo: ProofPhoto) {
  const delivery = await deliveryRepository.find(deliveryId)

  // Business rules leaked into use case!
  if (delivery.status !== 'in_transit') {
    throw new Error('Delivery not in transit')
  }
  if (!photo && delivery.requiresSignature) {
    throw new Error('Proof of delivery required')
  }

  delivery.status = 'delivered'
  delivery.proofPhoto = photo
  delivery.deliveredAt = new Date()
  await deliveryRepository.save(delivery)
}

// ✅ RIGHT - use case orchestrates, domain decides
async function confirmDropoff(deliveryId: DeliveryId, photo: ProofPhoto) {
  const delivery = await deliveryRepository.find(deliveryId)

  delivery.confirmDropoff(photo)  // Domain enforces the rules

  await deliveryRepository.save(delivery)
}
贫血模型的迹象:
  • 用例中充满if/else业务逻辑
  • 领域对象只是带有getter/setter的数据载体
  • 业务规则在多个用例中重复
  • 验证逻辑位于被验证对象之外

5. Separate generic concepts

5. 分离通用概念

What: Generic capabilities that aren't specific to your domain live separately from domain-specific logic.
Why: A retry mechanism, a caching layer, a validation framework—these aren't YOUR domain. Mixing them with domain logic obscures what's actually specific to your business.
Test: Would this code exist in a completely different business domain? If yes, it's generic. If it's specific to YOUR business rules, it's domain.
typescript
// ❌ WRONG - generic retry logic mixed with domain
// domain/driver-locator.ts
class DriverLocator {
  // Generic retry logic does not belong in domain!
  private async withRetry<T>(fn: () => Promise<T>, attempts: number): Promise<T> {
    for (let i = 0; i < attempts; i++) {
      try { return await fn() }
      catch (e) { if (i === attempts - 1) throw e }
    }
    throw new Error('Retry failed')
  }

  async findAvailableDriver(zone: Zone): Promise<Driver> {
    return this.withRetry(() => this.searchDriversInZone(zone), 3)
  }

  private async searchDriversInZone(zone: Zone): Promise<Driver> {
    // domain logic to find nearest available driver
  }
}

// ✅ RIGHT - same behavior, properly separated
// infra/retry.ts (generic, reusable in any project)
export async function withRetry<T>(fn: () => Promise<T>, attempts: number): Promise<T> {
  for (let i = 0; i < attempts; i++) {
    try { return await fn() }
    catch (e) { if (i === attempts - 1) throw e }
  }
  throw new Error('Retry failed')
}

// domain/driver-locator.ts (pure domain, no infra imports)
class DriverLocator {
  async findAvailableDriver(zone: Zone): Promise<Driver> {
    // domain logic to find nearest available driver
  }
}

// use-cases/dispatch-delivery.ts (orchestrates domain + infra)
async function dispatchDelivery(deliveryId: DeliveryId) {
  const delivery = await deliveryRepository.find(deliveryId)
  const driver = await withRetry(
    () => driverLocator.findAvailableDriver(delivery.zone), 3
  )
  delivery.assignDriver(driver)
  await deliveryRepository.save(delivery)
}

定义: 不特定于你的领域的通用能力,应与领域特定逻辑分离存放。
原因: 重试机制、缓存层、验证框架——这些不属于你的领域。将它们与领域逻辑混合会掩盖业务特有的内容。
验证方法: 这段代码会在完全不同的业务领域中存在吗?如果是,那它就是通用的;如果它特定于你的业务规则,那它就是领域相关的。
typescript
// ❌ WRONG - generic retry logic mixed with domain
// domain/driver-locator.ts
class DriverLocator {
  // Generic retry logic does not belong in domain!
  private async withRetry<T>(fn: () => Promise<T>, attempts: number): Promise<T> {
    for (let i = 0; i < attempts; i++) {
      try { return await fn() }
      catch (e) { if (i === attempts - 1) throw e }
    }
    throw new Error('Retry failed')
  }

  async findAvailableDriver(zone: Zone): Promise<Driver> {
    return this.withRetry(() => this.searchDriversInZone(zone), 3)
  }

  private async searchDriversInZone(zone: Zone): Promise<Driver> {
    // domain logic to find nearest available driver
  }
}

// ✅ RIGHT - same behavior, properly separated
// infra/retry.ts (generic, reusable in any project)
export async function withRetry<T>(fn: () => Promise<T>, attempts: number): Promise<T> {
  for (let i = 0; i < attempts; i++) {
    try { return await fn() }
    catch (e) { if (i === attempts - 1) throw e }
  }
  throw new Error('Retry failed')
}

// domain/driver-locator.ts (pure domain, no infra imports)
class DriverLocator {
  async findAvailableDriver(zone: Zone): Promise<Driver> {
    // domain logic to find nearest available driver
  }
}

// use-cases/dispatch-delivery.ts (orchestrates domain + infra)
async function dispatchDelivery(deliveryId: DeliveryId) {
  const delivery = await deliveryRepository.find(deliveryId)
  const driver = await withRetry(
    () => driverLocator.findAvailableDriver(delivery.zone), 3
  )
  delivery.assignDriver(driver)
  await deliveryRepository.save(delivery)
}

6. Make the implicit explicit... like your life depends on it

6. 将隐式概念显式化——就像事关生死一样重视

What: Strive for maximum expressiveness. Go as far as possible to identify and name domain concepts in code. Don't settle for "good enough"—push until the code speaks the domain fluently.
Why: Maximum alignment optimizes communication between engineers and domain experts. Easier to discuss nuances and avoid misconceptions. Easier to plan and implement features and detect when the design of code is causing unnecessary friction.
Test: Could you discuss this code with a domain expert without translation? Are there concepts they use that don't exist in your code?
typescript
// This code looks fine - isolated, uses domain terms
class Delivery {
  status: DeliveryStatus
  driver: Driver | null
  pickupTime: Date | null
  dropoffTime: Date | null
  proofOfDelivery: Photo | null

  assignDriver(driver: Driver): void {
    if (this.status !== DeliveryStatus.Confirmed) throw new Error('...')
    this.driver = driver
    this.status = DeliveryStatus.Assigned
  }

  recordPickup(): void {
    if (this.status !== DeliveryStatus.Assigned) throw new Error('...')
    this.pickupTime = new Date()
    this.status = DeliveryStatus.InTransit
  }

  recordDropoff(photo: Photo): void {
    if (this.status !== DeliveryStatus.InTransit) throw new Error('...')
    this.proofOfDelivery = photo
    this.dropoffTime = new Date()
    this.status = DeliveryStatus.Delivered
  }
}

// But the TYPES can describe the domain! Each state is a distinct concept.
// Reading the types alone tells you how deliveries work.

type Delivery =
  | RequestedDelivery      // Customer placed request
  | ConfirmedDelivery      // Restaurant accepted
  | AssignedDelivery       // Driver assigned, heading to restaurant
  | InTransitDelivery      // Driver picked up, heading to customer
  | DeliveredDelivery      // Complete with proof

interface RequestedDelivery {
  kind: 'requested'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
}

interface ConfirmedDelivery {
  kind: 'confirmed'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
  estimatedPrepTime: Duration
}

interface AssignedDelivery {
  kind: 'assigned'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
  driver: Driver              // Now guaranteed to exist
  estimatedPickup: Time
}

interface InTransitDelivery {
  kind: 'in_transit'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
  driver: Driver
  pickupTime: Time            // Now guaranteed to exist
  estimatedDropoff: Time
}

interface DeliveredDelivery {
  kind: 'delivered'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
  driver: Driver
  pickupTime: Time
  dropoffTime: Time           // Now guaranteed to exist
  proofOfDelivery: Photo      // Now guaranteed to exist
}

// State transitions are explicit functions
function confirmDelivery(d: RequestedDelivery, prepTime: Duration): ConfirmedDelivery
function assignDriver(d: ConfirmedDelivery, driver: Driver): AssignedDelivery
function recordPickup(d: AssignedDelivery): InTransitDelivery
function recordDropoff(d: InTransitDelivery, photo: Photo): DeliveredDelivery
Smaller improvements matter too:
typescript
// Extract an if statement to a named method
if (distance.kilometers > 10 && !driver.hasLongRangeVehicle) { ... }
if (delivery.exceedsDriverRange(driver)) { ... }

// Name a boolean expression
const canAssign = driver.isAvailable && driver.isInZone(delivery.zone) && !driver.atCapacity
const canAssign = driver.canAccept(delivery)

// Rename to use domain language
const fee = customFee ?? standardFee
const fee = customFee ?? defaultDeliveryFee
Ways to increase expressiveness:
  • Model states as distinct types (Delivery with status → RequestedDelivery, ConfirmedDelivery, etc.)
  • Make optional fields guaranteed at the right state (driver: Driver | null → driver: Driver)
  • Extract conditionals to named methods (complex if → exceedsDriverRange)
  • Rename variables to use domain language (standardFee → defaultDeliveryFee)

定义: 力求表达的最大化。尽可能在代码中识别并命名领域概念,不要满足于“足够好”——要推进到代码能流利表达领域语言的程度。
原因: 最大程度的对齐能优化工程师与领域专家之间的沟通,便于讨论细节、避免误解,便于规划和实现功能,也便于发现代码设计导致的不必要摩擦。
验证方法: 你能无需翻译就与领域专家讨论这段代码吗?他们使用的概念在你的代码中都存在吗?
typescript
// This code looks fine - isolated, uses domain terms
class Delivery {
  status: DeliveryStatus
  driver: Driver | null
  pickupTime: Date | null
  dropoffTime: Date | null
  proofOfDelivery: Photo | null

  assignDriver(driver: Driver): void {
    if (this.status !== DeliveryStatus.Confirmed) throw new Error('...')
    this.driver = driver
    this.status = DeliveryStatus.Assigned
  }

  recordPickup(): void {
    if (this.status !== DeliveryStatus.Assigned) throw new Error('...')
    this.pickupTime = new Date()
    this.status = DeliveryStatus.InTransit
  }

  recordDropoff(photo: Photo): void {
    if (this.status !== DeliveryStatus.InTransit) throw new Error('...')
    this.proofOfDelivery = photo
    this.dropoffTime = new Date()
    this.status = DeliveryStatus.Delivered
  }
}

// But the TYPES can describe the domain! Each state is a distinct concept.
// Reading the types alone tells you how deliveries work.

type Delivery =
  | RequestedDelivery      // Customer placed request
  | ConfirmedDelivery      // Restaurant accepted
  | AssignedDelivery       // Driver assigned, heading to restaurant
  | InTransitDelivery      // Driver picked up, heading to customer
  | DeliveredDelivery      // Complete with proof

interface RequestedDelivery {
  kind: 'requested'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
}

interface ConfirmedDelivery {
  kind: 'confirmed'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
  estimatedPrepTime: Duration
}

interface AssignedDelivery {
  kind: 'assigned'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
  driver: Driver              // Now guaranteed to exist
  estimatedPickup: Time
}

interface InTransitDelivery {
  kind: 'in_transit'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
  driver: Driver
  pickupTime: Time            // Now guaranteed to exist
  estimatedDropoff: Time
}

interface DeliveredDelivery {
  kind: 'delivered'
  customer: Customer
  restaurant: Restaurant
  items: MenuItem[]
  driver: Driver
  pickupTime: Time
  dropoffTime: Time           // Now guaranteed to exist
  proofOfDelivery: Photo      // Now guaranteed to exist
}

// State transitions are explicit functions
function confirmDelivery(d: RequestedDelivery, prepTime: Duration): ConfirmedDelivery
function assignDriver(d: ConfirmedDelivery, driver: Driver): AssignedDelivery
function recordPickup(d: AssignedDelivery): InTransitDelivery
function recordDropoff(d: InTransitDelivery, photo: Photo): DeliveredDelivery
小改进也很重要:
typescript
// Extract an if statement to a named method
if (distance.kilometers > 10 && !driver.hasLongRangeVehicle) { ... }
if (delivery.exceedsDriverRange(driver)) { ... }

// Name a boolean expression
const canAssign = driver.isAvailable && driver.isInZone(delivery.zone) && !driver.atCapacity
const canAssign = driver.canAccept(delivery)

// Rename to use domain language
const fee = customFee ?? standardFee
const fee = customFee ?? defaultDeliveryFee
提升表达力的方法:
  • 将状态建模为不同的类型(带状态的Delivery → RequestedDelivery、ConfirmedDelivery等)
  • 在正确的状态下保证可选字段的存在(driver: Driver | null → driver: Driver)
  • 将条件提取为命名方法(复杂if → exceedsDriverRange)
  • 重命名变量以使用领域语言(standardFee → defaultDeliveryFee)

7. Design aggregates around invariants

7. 围绕不变量设计聚合

What: An aggregate is a cluster of objects that must be consistent together. The aggregate root enforces the rules. External code cannot violate invariants.
Why: Without clear boundaries, inconsistent states creep in. One piece of code updates the delivery, another updates the route, and suddenly the ETA is wrong.
Test: What must be true at all times? What rules must never be broken? The objects involved in those rules form an aggregate.
typescript
// ❌ WRONG - no aggregate boundary, invariants violated
class Delivery {
  stops: DeliveryStop[]  // Exposed!
  totalDistance: Distance
}

// External code can break invariants
delivery.stops.push(new DeliveryStop(location))
// Oops - totalDistance is now wrong!

// ✅ RIGHT - aggregate protects invariants
class Delivery {
  private stops: DeliveryStop[] = []
  private _totalDistance: Distance = Distance.zero()

  addStop(location: Location): void {
    if (this.status !== DeliveryStatus.Planning) {
      throw new DeliveryNotModifiableError(this.id)
    }
    const previousStop = this.stops[this.stops.length - 1]
    const stop = new DeliveryStop(location)
    this.stops.push(stop)
    this._totalDistance = this._totalDistance.add(
      previousStop.distanceTo(location)  // Invariant maintained!
    )
  }

  removeStop(stopId: StopId): void {
    if (this.stops.length <= 2) {
      throw new MinimumStopsRequiredError(this.id)
    }
    // Recalculate total distance after removal
    this.stops = this.stops.filter(s => !s.id.equals(stopId))
    this._totalDistance = this.calculateTotalDistance()  // Invariant maintained!
  }

  get totalDistance(): Distance {
    return this._totalDistance
  }
}
Aggregate rules:
  • One root entity per aggregate
  • External code accesses only through the root
  • The root enforces all invariants
  • Reference other aggregates by ID, not object
  • Methods should operate on the same state—if they don't, split the aggregate

定义: 聚合是一组必须保持一致的对象集群,聚合根负责执行规则,外部代码不能违反不变量。
原因: 没有清晰的边界,不一致的状态会悄悄出现。一段代码更新配送信息,另一段更新路线,突然预计到达时间就出错了。
验证方法: 什么必须始终为真?哪些规则永远不能被打破?涉及这些规则的对象构成一个聚合。
typescript
// ❌ WRONG - no aggregate boundary, invariants violated
class Delivery {
  stops: DeliveryStop[]  // Exposed!
  totalDistance: Distance
}

// External code can break invariants
delivery.stops.push(new DeliveryStop(location))
// Oops - totalDistance is now wrong!

// ✅ RIGHT - aggregate protects invariants
class Delivery {
  private stops: DeliveryStop[] = []
  private _totalDistance: Distance = Distance.zero()

  addStop(location: Location): void {
    if (this.status !== DeliveryStatus.Planning) {
      throw new DeliveryNotModifiableError(this.id)
    }
    const previousStop = this.stops[this.stops.length - 1]
    const stop = new DeliveryStop(location)
    this.stops.push(stop)
    this._totalDistance = this._totalDistance.add(
      previousStop.distanceTo(location)  // Invariant maintained!
    )
  }

  removeStop(stopId: StopId): void {
    if (this.stops.length <= 2) {
      throw new MinimumStopsRequiredError(this.id)
    }
    // Recalculate total distance after removal
    this.stops = this.stops.filter(s => !s.id.equals(stopId))
    this._totalDistance = this.calculateTotalDistance()  // Invariant maintained!
  }

  get totalDistance(): Distance {
    return this._totalDistance
  }
}
聚合规则:
  • 每个聚合有一个根实体
  • 外部代码仅通过根实体访问
  • 根实体执行所有不变量规则
  • 通过ID引用其他聚合,而非对象
  • 方法应操作相同的状态——如果不是,拆分聚合

8. Extract immutable value objects liberally

8. 大量提取不可变值对象

What: When something is defined by its attributes (not identity), make it an immutable value object. Do this liberally—more value objects is usually better.
Why: Value objects are simple. They can't change unexpectedly. They're easy to test. They make domain concepts explicit. They're also a good way to extract logic from aggregates and entities that can easily get large—keep entities focused by pulling cohesive concepts into value objects.
Test: Does this need a unique ID to track it over time? No? It's probably a value object.
typescript
// Entity with primitives that should be a value object
class Delivery {
  id: DeliveryId
  feeAmount: number
  feeCurrency: string
}

// Extract the value object
class Delivery {
  id: DeliveryId
  fee: Money
}

class Money {
  constructor(
    readonly amount: number,
    readonly currency: Currency
  ) {}

  add(other: Money): Money {
    if (this.currency !== other.currency) {
      throw new CurrencyMismatchError(this.currency, other.currency)
    }
    return new Money(this.amount + other.amount, this.currency)
  }

  equals(other: Money): boolean {
    return this.amount === other.amount && this.currency === other.currency
  }
}
Good candidates for value objects:
  • Money, Currency, Percentage
  • DateRange, TimeSlot, Duration
  • Address, Coordinates, Distance
  • EmailAddress, PhoneNumber, URL
  • Quantity, Weight, Temperature
  • PersonName, CompanyName

定义: 当某事物由属性(而非标识)定义时,将其设为不可变值对象。要大量使用这种方式——值对象越多通常越好。
原因: 值对象简单,不会意外变更,易于测试,能显式表达领域概念。它们也是从可能变得庞大的聚合和实体中提取逻辑的好方法——通过将内聚概念提取到值对象中,保持实体的专注性。
验证方法: 它需要唯一ID来随时间追踪吗?不需要?那它很可能是值对象。
typescript
// Entity with primitives that should be a value object
class Delivery {
  id: DeliveryId
  feeAmount: number
  feeCurrency: string
}

// Extract the value object
class Delivery {
  id: DeliveryId
  fee: Money
}

class Money {
  constructor(
    readonly amount: number,
    readonly currency: Currency
  ) {}

  add(other: Money): Money {
    if (this.currency !== other.currency) {
      throw new CurrencyMismatchError(this.currency, other.currency)
    }
    return new Money(this.amount + other.amount, this.currency)
  }

  equals(other: Money): boolean {
    return this.amount === other.amount && this.currency === other.currency
  }
}
适合作为值对象的候选:
  • Money、Currency、Percentage
  • DateRange、TimeSlot、Duration
  • Address、Coordinates、Distance
  • EmailAddress、PhoneNumber、URL
  • Quantity、Weight、Temperature
  • PersonName、CompanyName

Mandatory Checklist

必查清单

When designing, refactoring, analyzing, or reviewing code:
  1. Verify domain is isolated from infrastructure (no DB/HTTP/logging in domain; generic utilities in infra; domain doesn't import infra)
  2. Verify names are from YOUR domain, not generic developer jargon
  3. Verify use cases are intentions of users, human or automated (apply the menu test)
  4. Verify business logic lives in domain objects, use cases only orchestrate
  5. Verify states are modeled as distinct types where appropriate
  6. Verify hidden domain concepts are extracted and named explicitly
  7. Verify aggregates are designed around invariants, not naive mapping of domain nouns
  8. Verify values are extracted into value objects expressing a domain concept
Do not proceed until all checks pass.
在设计、重构、分析或评审代码时:
  1. 验证领域与基础设施隔离(领域中无DB/HTTP/日志代码;通用工具在基础设施层;领域不导入基础设施代码)
  2. 验证命名来自你的领域,而非通用程序员行话
  3. 验证用例是用户(人类或自动化)的意图(应用菜单测试)
  4. 验证业务逻辑存在于领域对象中,用例仅负责编排
  5. 验证状态在合适的情况下被建模为不同的类型
  6. 验证隐藏的领域概念被提取并显式命名
  7. 验证聚合围绕不变量设计,而非对领域名词的简单映射
  8. 验证值被提取为表达领域概念的值对象
在所有检查通过前不要继续。