Tactical Design

เมื่อรู้ขอบเขตแล้ว เราลงมือสร้าง Domain Model ที่ “รวยพฤติกรรม” ด้วย building blocks ของ DDD Fowler จัดกลุ่มหลักไว้สามอย่าง (Evans Classification): Entity, Value Object, และ service

Entity — แยกแยะด้วยตัวตน

Entity คืออ็อบเจ็กต์ที่มี Identity ต่อเนื่องตามเวลา แม้ค่าภายในเปลี่ยน ก็ยังเป็น “สิ่งเดิม” เช่น ลูกค้าคนหนึ่งเปลี่ยนชื่อ–ที่อยู่ได้ แต่ก็ยังเป็นลูกค้าคนเดิม เราแยกแยะด้วย id ไม่ใช่ด้วยค่า และที่สำคัญ Entity ต้อง “มีพฤติกรรม” ไม่ใช่แค่เก็บข้อมูล

Value Object — แยกแยะด้วยค่า

Value Object คืออ็อบเจ็กต์ที่เราสนใจแค่ “ค่า” ของมัน ไม่มีตัวตนเฉพาะ สองตัวที่ค่าเท่ากันถือว่าเท่ากัน เช่น เงิน 100 บาท ก็คือ 100 บาท ไม่ว่าจะเป็นวัตถุไหน กฎสำคัญคือควรเป็น Immutable — ถ้าจะเปลี่ยนค่า ให้สร้างตัวใหม่แทน เพื่อเลี่ยง bug จากการใช้อ้างอิงร่วมกัน

// Value Object: เทียบกันด้วยค่า, เปลี่ยนแปลงไม่ได้, validate ตอนสร้าง
class Money {
  private constructor(
    readonly amountSatang: number,  // เก็บเป็นสตางค์ (เลขจำนวนเต็ม) เลี่ยงปัญหาทศนิยม
    readonly currency: string,
  ) {}

  static of(amountSatang: number, currency: string): Money {
    if (!Number.isInteger(amountSatang)) throw new Error('ต้องเป็นจำนวนเต็ม');
    if (amountSatang < 0) throw new Error('เงินติดลบไม่ได้');
    return new Money(amountSatang, currency);
  }

  add(other: Money): Money {
    if (other.currency !== this.currency) throw new Error('สกุลเงินไม่ตรงกัน');
    return Money.of(this.amountSatang + other.amountSatang, this.currency); // คืนตัวใหม่
  }

  equals(other: Money): boolean {            // เท่ากันเมื่อค่าทุกตัวเท่ากัน
    return this.amountSatang === other.amountSatang && this.currency === other.currency;
  }
}

Aggregate — หัวใจของ Tactical Design

Aggregate คือกลุ่มของ Entity และ Value Object ที่ถูกมองเป็น “หนึ่งหน่วยเดียว” เพื่อรักษาความถูกต้องของข้อมูล มี Aggregate Root เป็นประตูเดียวเข้าสู่กลุ่ม การอ้างอิงจากภายนอกทำได้กับ root เท่านั้น Fowler ย้ำกฎสำคัญ: “transaction ไม่ควรข้ามขอบเขตของ Aggregate”

Cargo Aggregate — ขอบเขตความถูกต้อง

aggregate

Aggregate RootValue Objectขอบเขต (boundary)

กฎข้อ 1 & 2: สิ่งที่อยู่ ภายใน ขอบเขต Cargo ต้องถูกต้องตาม invariant พร้อมกันภายใน หนึ่ง transaction — และควรออกแบบให้เล็กที่สุด

ไดอะแกรม Aggregate ของ Cargo — ขอบเขตความถูกต้อง (invariant) ภายในหนึ่ง transaction

สี่กฎการออกแบบ Aggregate (Vaughn Vernon)

1. จำลอง Invariant ที่แท้จริงไว้ในขอบเขตความถูกต้อง — กฎที่ต้องตรงกันทันทีต้องอยู่ใน Aggregate เดียวกันและถูกต้องภายใน transaction เดียว

2. ออกแบบ Aggregate ให้เล็ก — จำกัดให้เหลือ root กับสิ่งจำเป็นน้อยที่สุด Aggregate ใหญ่จะ “ไม่มีวันเร็วหรือสเกลได้ดี”

3. อ้างอิง Aggregate อื่นด้วย Identity — เก็บแค่ id ของอีก Aggregate ไม่ใช่อ้างอิงตรง ป้องกันการแก้หลาย Aggregate ใน transaction เดียว และ map เข้ากับขอบเขต microservice ได้ดี

4. ใช้ Eventual Consistency นอกขอบเขต — เมื่อกระบวนการธุรกิจกระทบหลาย Aggregate ให้ส่ง Domain Event แล้วประมวลผลตามมาแบบ async

// Order = Aggregate Root; OrderLine อยู่ภายในขอบเขต
class Order {                          // <- Aggregate Root
  private lines: OrderLine[] = [];
  private constructor(readonly id: OrderId, private status: OrderStatus) {}

  // พฤติกรรมอยู่บน root และคอย “บังคับ invariant”
  addLine(product: ProductId, qty: number, price: Money): void {
    if (this.status !== 'DRAFT') throw new Error('แก้คำสั่งซื้อที่ยืนยันแล้วไม่ได้');
    this.lines.push(new OrderLine(product, qty, price));
  }

  total(): Money {                     // invariant: ยอดรวม = ผลรวมของรายการ
    return this.lines.reduce((sum, l) => sum.add(l.subtotal()), Money.of(0, 'THB'));
  }

  confirm(): DomainEvent {
    if (this.lines.length === 0) throw new Error('คำสั่งซื้อว่างเปล่ายืนยันไม่ได้');
    this.status = 'CONFIRMED';
    return new OrderConfirmed(this.id, this.total());  // ส่ง event ออกไป (กฎข้อ 4)
  }
}

class OrderLine {                      // ภายใน Aggregate — ไม่มีใครอ้างจากนอกได้
  constructor(readonly product: ProductId, readonly qty: number, readonly price: Money) {}
  subtotal(): Money { return this.price.times(this.qty); }
}

🚢 ทำไม Handling Event จึงเป็น Aggregate แยก?

ในระบบขนส่ง Cargo (ระบุตัวด้วย Tracking ID ตั้งแต่จองจนส่งมอบ) เป็น Aggregate Root (มี Route Specification, Itinerary, Delivery อยู่ภายใน) ส่วน Handling Event — การบันทึกว่าสินค้าถูกยก/ลง/รับ ณ ท่าใด — เป็น Aggregate แยกต่างหาก

เหตุผลคือ “ประสิทธิภาพ”: Handling Event หลั่งไหลเข้ามาปริมาณมหาศาลจากระบบท่าเรือ/คลังภายนอก และต้องประมวลผลเร็วแบบ async จึงไม่ควรโหลดมาพร้อมโครงสร้าง Cargo ที่ใหญ่ — ตรงกับกฎ “ออกแบบให้เล็ก” และ “อ้างอิงด้วย id” พอดี

Repository — เข้าถึง Aggregate

Repository ทำให้เราเข้าถึง Aggregate ราวกับเป็น collection ในหน่วยความจำ โดยซ่อนรายละเอียดฐานข้อมูล หลักการคือ 1 repository ต่อหนึ่ง Aggregate Root และ interface ควรนิยามไว้ในชั้น domain ส่วน implementation อยู่ชั้น infrastructure เพื่อไม่ให้ ORM มา “ปนเปื้อน” model (เราจะเห็นเหตุผลชัดขึ้นในเรื่องสถาปัตยกรรม)

// interface อยู่ในชั้น domain — domain บอกแค่ว่า “ต้องการอะไร”
interface OrderRepository {
  findById(id: OrderId): Promise<Order | null>;
  save(order: Order): Promise<void>;
  nextId(): OrderId;
}
// implementation จริง (เช่น Drizzle/Postgres) อยู่ชั้น infrastructure แยกต่างหาก

Domain Service กับ Application Service

เมื่อตรรกะธุรกิจสำคัญ “ไม่เข้า” กับ Entity หรือ Value Object ตัวใดตัวหนึ่งโดยธรรมชาติ ให้ทำเป็น Domain Service เช่น การหาเส้นทาง หรือการโอนเงินที่กระทบสองบัญชี ส่วน Application Service ทำหน้าที่ “ประสานงาน” use case — เปิด transaction, จัดการสิทธิ์, เรียก repository — แต่ ไม่มีกฎธุรกิจในตัวเอง

เส้นแบ่งที่จำง่าย

Domain Service = ถือ “การตัดสินใจทางธุรกิจ” · Application Service = ประสานงานการตัดสินใจเหล่านั้น (เหมือนที่มันประสานงานการเรียก method บน Entity) ถ้า Application Service เริ่มมีกฎธุรกิจ นั่นคือสัญญาณว่ากำลังจะกลายเป็น Anemic Domain Model

Domain Event และ Factory

Domain Event แทน “สิ่งที่เกิดขึ้นแล้ว” ใน domain ที่ส่วนอื่นสนใจ ตั้งชื่อเป็นอดีตเสมอ (เช่น CargoWasRouted, OrderConfirmed) เป็น Immutable และมักพก timestamp กับ id ของสิ่งที่เกี่ยวข้อง ใช้เพื่อทำ side-effect ข้าม Aggregate และเปิดทาง Eventual Consistency ส่วน Factory ห่อหุ้มการ “สร้าง” Aggregate ที่ซับซ้อนให้ถูกต้องตาม invariant ตั้งแต่แรก — Evans เปรียบว่า “factory สร้างของใหม่ ส่วน repository หาของเก่า” ส่วน Module คือการจัดกลุ่มแนวคิดที่เกี่ยวข้องกันไว้ด้วยกัน (เช่น package) โดยตั้งชื่อกลุ่มด้วยคำใน Ubiquitous Language ไม่ใช่ตั้งตามชนิดทางเทคนิค

Anti-pattern สำคัญ: Anemic Domain Model

Anemic Domain Model คือกับดักที่พบบ่อยที่สุด: อ็อบเจ็กต์ดูเหมือน domain model มีชื่อตรงกับคำในธุรกิจ แต่ “แทบไม่มีพฤติกรรม” เป็นเพียง “ถุงใส่ getter/setter” ส่วนตรรกะทั้งหมดถูกผลักไปไว้ในชั้น service Fowler เรียกว่าขัดกับแก่นของ OOP โดยสิ้นเชิง เพราะ OOP คือการรวมข้อมูลกับพฤติกรรมเข้าด้วยกัน

ปัญหาของ anemic domain model คือมันแบกต้นทุนทั้งหมดของ domain model โดยไม่ได้ประโยชน์ของมันเลย

— ใจความจาก Martin Fowler

แต่ — ไม่ใช่ทุกที่ต้องรวย

Microsoft ตั้งข้อสังเกตว่า ถ้า Bounded Context นั้นง่ายมาก (เป็น CRUD ล้วน เช่น catalog สินค้า) anemic model ก็ “ดีพอ” ได้ ไม่ต้องฝืนใช้ DDD เต็มรูปแบบทุกที่ — ขึ้นกับว่ากำลังสร้างอะไร (เรื่องนี้เชื่อมกับ Stage 5)

🔗 อ้างอิงเพิ่มเติมใน DevIQ

เจาะลึกแนวคิดในบทนี้ต่อได้ที่คลังอ้างอิง DevIQ:

Entity — ขยายความเรื่องการแยกแยะด้วย identity และทำไม Entity ต้อง “มีพฤติกรรม” ไม่ใช่แค่เก็บข้อมูล
Value Object — หลักการ immutability และ self-validation ที่ตัวอย่าง Money ใช้
Aggregate — รายละเอียดเรื่อง Aggregate Root และขอบเขตความถูกต้อง (invariant boundary) ที่ต่อยอดจากสี่กฎของ Vernon
Repository — pattern เต็มรูปแบบเบื้องหลัง interface OrderRepository และเหตุผลที่ domain ไม่ควรขึ้นกับ ORM
Anemic Domain Model — วิเคราะห์ anti-pattern นี้ลึกขึ้น พร้อมวิธีสังเกตและหลีกเลี่ยง

เช็กความเข้าใจ — Stage 3

ข้อ 1 / 5

อะไรคือความต่างหลักระหว่าง Entity กับ Value Object?