Application Architecture — สถาปัตยกรรมที่ปกป้อง domain model

จนถึงตอนนี้คอร์สเราพูดถึงแต่ “วิธีสร้าง model” ที่เข้าใจ problem domain — แต่ model ที่ดีจะไร้ค่าทันที หากถูกกลืนหายไปใน code ของฐานข้อมูล framework และ UI บทนี้จึงเปลี่ยนคำถามจาก “จะสร้าง model อย่างไร” เป็น “จะ วาง model ไว้ตรงไหน ใน app จริง เพื่อให้มันอยู่รอดและไม่ถูกปนเปื้อน”

หัวใจของบทนี้สั้นมาก: Domain-Driven Design ไม่บังคับ ให้คุณใช้สถาปัตยกรรมแบบใดแบบหนึ่ง แต่สถาปัตยกรรมที่คุณเลือก ต้องทำสิ่งเดียวให้ได้ — แยก domain logic ออกจาก technical concern อย่างเด็ดขาด ถ้าทำไม่ได้ codebase จะค่อยๆ เสื่อมกลับไปเป็น Big Ball of Mud เหมือนเดิม

แยก concern เพื่อปกป้องความถูกต้องของ model

code ใน app หนึ่งๆ มี concern หลายชนิดที่ เปลี่ยนด้วยอัตราต่างกันและด้วยเหตุผลต่างกัน — presentation (UI) เปลี่ยนบ่อยตาม design, persistence เปลี่ยนตามเทคโนโลยีฐานข้อมูล, ส่วน domain logic เปลี่ยนตามกฎธุรกิจ ถ้าทั้งสามปนกันอยู่ใน file เดียว การแก้ design ปุ่มอาจไปทำกฎธุรกิจพังโดยไม่ตั้งใจ

DDD ต้องการสถาปัตยกรรมที่ทำสองอย่าง:

Separation of concerns — แยกความซับซ้อนทางเทคนิคออกจากความซับซ้อนของ domain ให้แต่ละส่วนเปลี่ยนได้โดยไม่กระทบกัน
Abstraction จากรายละเอียดของ domain — เปิดให้โลกภายนอกเรียกใช้ผ่านชุด use case แบบ coarse-grained (หยาบในระดับธุรกิจ) แทนที่จะให้ client เข้าไปยุ่งกับ domain object โดยตรง

แก่นของทั้งบท

สถาปัตยกรรมในมุมมอง DDD มีหน้าที่เดียว: กัน domain model ไว้ตรงใจกลาง ไม่ให้รายละเอียดทางเทคนิคเข้ามาแตะต้อง ไม่ว่าจะเป็น Layered, Hexagonal, Onion หรือ Clean Architecture — ทุกแบบล้วนรับใช้เป้าหมายเดียวกันนี้

Layered Architecture: domain อยู่แกนกลาง

วิธีที่คลาสสิกที่สุดในการแยก concern คือการแบ่ง app เป็น ชั้น (layer) ตามความรับผิดชอบ Martin Fowler รวบรวมรูปแบบ Layered Architecture ไว้ในหนังสือ Patterns of Enterprise Application Architecture และยังมีสถาปัตยกรรมอื่นที่เป้าหมายเดียวกัน เช่น Clean Architecture ของ Uncle Bob (Robert C. Martin), Hexagonal Architecture (Ports and Adapters) และ Onion Architecture

แต่ภาพของ DDD ต่างจาก layered architecture แบบเรียงชั้นทั่วไป — รูปที่ 8-1 วาดมันเป็น วงกลมซ้อนกัน โดยมี domain layer อยู่ใจกลาง

รูปที่ 8-1: Layered Architecture แบบ DDD — domain layer อยู่แกนกลาง ห่อด้วย application layer แล้วจึงเป็น infrastructure (presentation, persistence, web services, messaging, SMTP) ที่อยู่วงนอกสุด

Domain Layer (แกนกลาง) — บรรจุตรรกะธุรกิจทั้งหมด ไม่รู้จักและไม่ขึ้นกับเทคโนโลยีใดๆ เลย
Application Layer (ห่อรอบ domain) — เปิด API ระดับหยาบ ที่แทน business use case โดยซ่อนรายละเอียดระดับล่างของ domain เอาไว้
Infrastructure Layers (วงนอก) — รายละเอียดทางเทคนิคล้วนๆ: UI, ฐานข้อมูล, web service, การส่งอีเมล

จุดสำคัญคือ domain layer และ application layer ถูก isolate และปกป้อง จาก accidental complexity ของ client framework และ infrastructure ทั้งหมด

Dependency Inversion: ทุก dependency ชี้เข้าด้านใน

ทำไมวงในถึงไม่ถูกปนเปื้อน? เพราะกฎเหล็กข้อเดียว — dependency ทุกเส้นต้องชี้เข้าหาแกนกลาง domain layer ที่อยู่ใจกลางไม่พึ่งพาอะไรเลย จึงโฟกัสที่เรื่อง domain ได้แบบไร้สิ่งรบกวน ส่วน application layer พึ่งพาเฉพาะ domain layer เท่านั้น

รูปที่ 8-2: Dependency inversion ใน Layered Architecture — application layer เป็นฝ่ายนิยาม interface ที่ตัวเองต้องการ แล้ว infrastructure วงนอกเป็นฝ่ายมา implement ตาม ทำให้ลูกศร dependency ชี้กลับเข้าด้านใน

แล้ว state ของ domain object ที่ต้องบันทึกลงฐานข้อมูลล่ะ? นี่คือจุดที่ Dependency Inversion เปล่งประกาย แทนที่ domain จะไปเรียกฐานข้อมูล (ซึ่งจะทำให้ domain ผูกติดกับเทคนิค) เรากลับทิศความสัมพันธ์เสียใหม่:

Application layer เป็นฝ่ายนิยาม interface — เขียนด้วยภาษาและมุมมองของ application เอง ปลอดจากศัพท์เทคนิคของ framework ใดๆ เช่น interface ที่บอกว่า “ขอ hydrate และ persist domain object”
Infrastructure layer เป็นฝ่าย implement interface นั้น — มาเสียบเข้ากับ Port ที่วงในเปิดไว้ในฐานะ Adapter

เรื่อง transaction management, security, logging (cross-cutting concern) ก็จัดการด้วยวิธีเดียวกัน

🚢 Cargo Shipping — interface เป็นของ domain

ใน Cargo Shipping ฝั่ง domain เรานิยาม CargoRepository ในฐานะ interface ที่ อยู่ในวงใน — มันพูดภาษาธุรกิจล้วนๆ: find(trackingId), store(cargo) ไม่มีคำว่า SQL หรือ table อยู่เลย

ส่วน SqlCargoRepository ที่รู้จัก connection string และตาราง cargo ถูกวางไว้ในวง infrastructure แล้วมา implement interface นั้น ผลคือเราสลับจาก SQL ไป NoSQL ได้โดย ไม่ต้องแตะ domain layer แม้แต่บรรทัดเดียว

// interface นี้อยู่ "วงใน" — domain เป็นฝ่ายกำหนดว่าตัวเองต้องการอะไร
// โลกภายนอกต้องปรับตัวมาทำตาม ไม่ใช่กลับกัน
interface CargoRepository {
  find(trackingId: TrackingId): Cargo | null;
  store(cargo: Cargo): void;
}

สามชั้นทำงานร่วมกันอย่างไร

Domain Layer — หัวใจที่ไม่รู้จักโลกภายนอก

ตามที่เราเรียนใน Model-Driven Design domain model คือภาพนามธรรมของ problem domain ที่สร้างขึ้นเพื่อตอบ business use case domain layer ที่บรรจุ model นี้ ไม่พึ่งพาอะไรเลย และไม่สนใจว่า client เป็นใครหรือข้อมูลถูกเก็บที่ไหน

Application Service Layer — façade ของ use case

application service layer แทน use case และกระบวนการธุรกิจ (business process) ของ app มันทำงานที่ระดับ abstraction สูงกว่า domain object — เปิดบริการระดับหยาบในเชิงธุรกิจ และซ่อนรายละเอียดของ domain ไว้หลัง façade บอกว่า “ระบบทำอะไรได้” แต่ไม่บอก “ทำอย่างไร” ผลคือเราพัฒนา model ด้านในต่อไปได้โดยไม่กระทบ client

มุมมองที่ทรงพลังมากคือ: application layer ทำตัวเป็น Anticorruption Layer — client ใหม่ทุกตัวต้องปรับตัวเข้าหา contract (API) ของ app และต้องแปลง output เอง ไม่ใช่ให้ app ไปปรับตามใจ client วิธีนี้ทำให้ domain layer “บริสุทธิ์” ไม่ถูกรายละเอียดทางเทคนิคภายนอกมาแปดเปื้อน

Infrastructure Layers — รายละเอียดทางเทคนิคล้วนๆ

infrastructure คือสิ่งที่ทำให้ app “ทำงานได้จริง”: การเปิดให้คนเข้าถึงผ่าน UI หรือให้ระบบอื่นเข้าถึงผ่าน web service/message endpoint, การ implement การจัดเก็บ state, logging, security, notification และการ integrate กับ bounded context อื่น ทั้งหมดนี้เป็น “รายละเอียดภายนอก” ที่ไม่ควรกระทบ use case และ domain logic โดยตรง

สื่อสารข้ามชั้นโดยไม่ปล่อย domain object รั่ว

เมื่อข้อมูลวิ่งข้ามขอบเขตของชั้น มีกฎสองข้อ:

อย่าส่ง domain object ออกไปข้ามขอบเขต — เพราะนั่นคือการเปิดเผยโครงสร้างภายในของ model ให้โลกภายนอก
อย่าปล่อยข้อมูลดิบหรือ user input ตรงเข้า domain layer — ต้องผ่านการแปลงก่อนเสมอ

แทนที่จะส่ง domain object เราใช้ DTO (Data Transfer Object), presentation model และ application event object เป็นตัวกลางสื่อสารการเปลี่ยนแปลง ชั้นที่อยู่สูงกว่าต้องปรับตัวเข้าหา message type ของชั้นที่ต่ำกว่า ทำให้วงในยังคง isolate และ loosely coupled

class BookCargoService {
  bookCargo(request: BookCargoRequest): BookingResult {
    // 1) แปลง input ดิบ -> Value Object ที่ domain เข้าใจ
    const spec = new RouteSpecification(request.origin, request.destination, request.deadline);
    const cargo = Cargo.book(this.trackingIdFactory.next(), spec);

    this.cargoRepository.store(cargo);

    // 2) แปลง domain object -> DTO ก่อนส่งกลับ ไม่ปล่อย Cargo รั่วออกไป
    return new BookingResult(cargo.trackingId.value, cargo.routingStatus);
  }
}

ทดสอบแยกส่วนได้ เพราะแยก concern แล้ว

ผลพลอยได้ที่ยอดเยี่ยมของการแยก concern คือ ทดสอบได้ง่ายขึ้นมาก เมื่อ domain logic ไม่ผูกกับ code เชิงเทคนิค (UI, persistence framework) เราทดสอบ domain และ application logic แบบ isolate ได้

Domain layer — ใช้ unit test ยืนยันตรรกะล้วนๆ ได้เลย ไม่ต้องมีฐานข้อมูล
Application layer — ใช้ mock/stub แทน external resource เพื่อยืนยันว่ามันประสานงาน (coordinate) ระหว่าง domain กับ infrastructure ถูกต้อง
Infrastructure layer — เน้น integration test และ end-to-end test แทน เพราะมันคือจุดที่แตะของจริง

การแยก concern ต้องลามไปถึง persistence ด้วย วิธี integrate ที่ดูง่ายแต่อันตรายคือ การให้หลาย app ใช้ฐานข้อมูลและ schema ชุดเดียวกัน

กับดัก: shared database = ทางลัดสู่ Big Ball of Mud

การ share schema เปิดช่องให้ client หลบเลี่ยงกลไกป้องกันของ Bounded Context ได้โดยง่าย — มันเขียนทับ state ของ domain object ได้โดยตรง ข้าม domain logic ที่ควรเป็นผู้บังคับ Invariant ผลที่ตามมาคือข้อมูลที่ละเมิดกฎธุรกิจ และเส้นแบ่งของ model ที่พร่าเลือนจนกลายเป็น BBoM

ทางที่ถูกคือ favor application/bounded-context database มากกว่า integration database — bounded context สองตัวอาจใช้เครื่องฐานข้อมูลร่วมกันได้ แต่ schema ต้องแยกกัน (ในอุดมคติคือต่างฐานข้อมูลไปเลย) เหมือนที่เราลากเส้น context boundary ใน model เราต้องลากเส้นเดียวกันกับ persistence model ด้วย เพื่อบังคับให้ทุกคน integrate ผ่าน application service layer ที่นิยามไว้ชัดเจน

สถาปัตยกรรมของ app ≠ สถาปัตยกรรมของ Bounded Context

app หนึ่งตัวอาจประกอบด้วย bounded context มากกว่าหนึ่ง ตัว และสถาปัตยกรรมก็ใช้กับ “app” และ “bounded context” คนละแบบกัน

graph TD
  UI["Presentation Layer<br/>(มี application layer ของตัวเองเพื่อประสาน context)"]
  UI --> BCA["Bounded Context A<br/>Domain Model Pattern"]
  UI --> BCB["Bounded Context B<br/>Transaction Script"]
  UI --> BCC["Bounded Context C<br/>Table Module"]

สังเกตว่าแต่ละ bounded context เลือกวิธีแทน domain logic ของตัวเองได้อิสระ — context ที่ตรรกะรวยอาจใช้ Domain Model pattern ส่วน context ที่งานง่ายๆ อาจใช้ Transaction Script หรือ Table Module ก็ได้

มีอีกสำนักคิด (Udi Dahan’s business component) ที่เชื่อว่าขอบเขตของ bounded context ควรขยายไปถึง presentation layer ด้วย — คือให้แต่ละ context เป็นเจ้าของส่วน UI เฉพาะของมันเอง โดยมี infrastructure คอยจัดการการสื่อสารและ correlation ID

หลักการที่จำให้แม่น

ไม่จำเป็น ต้องใช้สถาปัตยกรรมหรือ data store แบบเดียวกันทั่วทุก bounded context — แต่ ภายใน bounded context เดียว ควรยึดวิธีแทน domain logic แบบเดียวให้สม่ำเสมอ

Application Logic ≠ Domain Logic

นี่คือเส้นแบ่งที่คนสับสนบ่อยที่สุด รูปที่ 8-9 แยกให้เห็นชัด

รูปที่ 8-9: Application logic เทียบกับ Domain logic — application service ทำหน้าที่ validate input, ดึง domain object จาก data store, มอบหมายการตัดสินใจให้ domain object และแจ้ง event ไปยังระบบอื่น ส่วนการตัดสินใจเชิงธุรกิจอยู่ที่แกน Domain Layer

Application logic = ขั้นตอน workflow เพื่อทำ use case ให้สำเร็จ เช่น hydrate domain object จากฐานข้อมูล, map user input เป็น object ที่ domain เข้าใจ, มอบหมาย (delegate) ให้ domain ตัดสินใจ, แล้วแจ้งระบบอื่นผ่าน messaging มันเป็นเรื่องของ coordination และ orchestration ผ่านการ delegate — application service เอง “ไม่ลงมือทำงานจริง” แต่รู้ว่า “ต้องคุยกับใคร” เพื่อให้งานสำเร็จ จึงควรเป็น code แบบ procedural ที่ บาง (thin)

Domain logic = กฎ แนวคิด ข้อมูล และ flow ของ domain ล้วนๆ ปลอดจากรายละเอียดเทคนิครวมถึง persistence

🛒 e-commerce — ใส่คูปองส่วนลดลงตะกร้า

ลองดู use case “ใช้คูปองกับตะกร้า” ตามรูป 8-9:

presentation layer (เช่น ASP.NET MVC) แปลง HTTP request เป็นรูปแบบที่ application service ต้องการ แล้วเรียก service method — นี่คือ application logic
application service delegate ไป persistence เพื่อดึง object Coupon มา แล้วเช็กว่ายังใช้ได้ไหม — coordination = application logic
ถ้าใช้ได้ มันดึง Basket มา แล้ว ส่ง basket ให้ coupon เป็นฝ่ายคำนวณส่วนลดเอง — การคำนวณส่วนลดคือ domain logic อยู่ใน domain object
บันทึกการเปลี่ยนแปลง แล้ว publish event ว่า coupon ถูก redeem — กลับมาเป็น application logic

เห็นไหมว่า service เป็นเพียง “ผู้ควบคุมวง” ส่วนการตัดสินใจเชิงธุรกิจถูกผลักเข้าไปไว้ใน domain object เสมอ

อย่าให้ domain logic หลุดเข้าไปใน application service

ถ้าคุณพบเงื่อนไข if ที่เป็นกฎธุรกิจ (เช่น “ส่วนลดเกิน 50% ต้องให้ผู้จัดการอนุมัติ”) อยู่ใน application service — นั่นคือสัญญาณว่าตรรกะกำลังรั่วไหลออกจาก domain ปลายทางคือ Anemic Domain Model ที่ domain object เหลือแต่ getter/setter ส่วนกฎทั้งหมดกระจัดกระจายอยู่ใน service

Application Service แทน Use Case ไม่ใช่ CRUD

เพราะ application service เปิดเผย ความสามารถของระบบ มันจึงไม่ควรเปลี่ยนตาม client — client ต่างหากที่ต้องปรับตัวเข้าหา contract ของ service capability ของระบบควรเปลี่ยน ก็ต่อเมื่อ business use case เปลี่ยน เท่านั้น ซึ่งเกิดด้วยอัตราและเหตุผลต่างจาก domain logic ที่อยู่เบื้องหลัง — นี่เองที่ปกป้อง client จากการเปลี่ยนแปลงบ่อยๆ ของ domain

ตัวอย่าง: use case “ประเมินความเสี่ยงทุจริตของออเดอร์” — domain logic ภายในอาจเปลี่ยนวิธีคำนวณคะแนนไปเรื่อยๆ แต่ application service ที่เป็น “หน้าตา” ของ use case นั้นแทบไม่เปลี่ยน จะเปลี่ยนก็เฉพาะตอนแก้ contract เพื่อให้ข้อมูลเพิ่ม

application service จึงควรตั้งชื่อให้ เผยเจตนาของผู้ใช้ ไม่ใช่ตั้งตาม CRUD — Behavior-Driven Design (BDD) ช่วยให้เราจับกระบวนการธุรกิจ (business process) ของระบบ แล้วนำภาษาจาก BDD specification มาตั้งชื่อ use case เหมือนที่เราใช้ Ubiquitous Language ใน code ของ domain layer

Application Service เผยว่าต้องมี domain model ไหม

method ของ application service เป็นเครื่องชี้วัดที่ดี: ถ้าทุก use case เป็นแค่ add/update/delete ข้อมูลเฉยๆ แสดงว่า domain แทบไม่มีตรรกะจริง — ใช้ Transaction Script ก็พอ ไม่ต้องลงทุนทำ rich domain model แต่ถ้า service และกระบวนการธุรกิจ (business process) เต็มไปด้วยภาษาเชิงธุรกิจที่รวย นั่นคือสัญญาณว่าควรใช้ Domain Model pattern

Domain Reporting: Read Model แยกจาก Transactional Model

นอกจากประสานงาน application service ยังต้อง รายงาน state ของ domain ออกมาเป็น view แต่เราไม่อยากเปิดโครงสร้างภายในของ model จึงแปลง domain object เป็น presentation/view model ที่ให้เฉพาะมุมที่ต้องการ

รูปที่ 8-10: View model ดึงข้อมูลจากหลาย Aggregate — บาง view ต้องการข้อมูลข้าม Aggregate A, B, C การ hydrate domain object ทั้งหมดเพื่อแสดงข้อมูลแค่บางส่วนนั้นแพงและไม่คุ้ม

ปัญหาคือ บาง view ต้องการข้อมูลที่ ข้ามหลาย Aggregate การ hydrate domain object ที่รวยทั้งก้อนเพียงเพื่อแสดงข้อมูลเพียงบางส่วนบนหน้าจอนั้นสิ้นเปลืองโดยใช่เหตุ ทางที่ดีกว่าคือให้ application service ดึง view ออกมา ตรงจาก data source โดยไม่ต้องประกอบ object graph ขนาดใหญ่

แต่การให้ทั้ง read และ write ใช้ model เดียวกันมีข้อเสีย — ความต้องการของ view อาจบีบให้โครงสร้างของ domain object ต้องเปลี่ยนตามความต้องการของ presentation เพื่อกันเรื่องนี้ เราเก็บข้อมูลสำหรับอ่านไว้ใน schema แยกที่เหมาะกับการ query โดยอาจอาศัยการบันทึก event ที่เกิดใน model มาเป็นฐานของรายงาน

รูปแบบที่แยก “ฝั่งเขียน” (transactional model) ออกจาก “ฝั่งอ่าน” (read model) อย่างชัดเจนนี้เรียกว่า CQRS (Command Query Responsibility Segregation) — เราจะลงลึกในบทหลัง

Application Clients: service ต้องไม่รู้จัก client

หน้าที่ของ client คือ “เปิดเผยความสามารถของระบบสู่ผู้ใช้” — บาง app มี UI, บาง app เปิดเป็น REST/web service ไม่ว่าแบบไหน หลักการเดียวคือ service ต้องไม่รู้และไม่สนว่าใครเรียกใช้มัน application service ไม่ควรดัดตัวเองให้เข้ากับ client แต่ควรเปิด use case แล้วบังคับให้ client ปรับตัวเข้าหา API

รูปที่ 8-13: client หลายแบบเรียกใช้พฤติกรรมของ app ผ่าน application service layer เดียวกัน — ทั้ง presentation, web service, messaging โดยที่ application service เองก็เรียกใช้ context ภายนอกและ third-party service ได้ด้วย

จริงๆ แล้วคุณ สร้างระบบโดยไม่มี application service layer ก็ได้ — ปล่อยให้ client ทำงานทั้งหมดแทน แต่การสร้างชุด service ที่ชัดเจนทำให้คุณ model use case ออกมาเป็นรูปธรรม และแยกมันออกจากความต้องการของ presentation ทำให้โฟกัสที่พฤติกรรมของระบบและแยก domain logic ออกจาก concern อื่นได้สะอาด

bounded context หลายตัวประกอบกันเป็นระบบใหญ่ผ่าน technical infrastructure (เช่น messaging) และเมื่อกระบวนการธุรกิจ (business process) พาดผ่าน หลาย bounded context เราใช้ Process Manager มาประสานงาน — มันคล้าย application service คือ stateless (ยกเว้น state ที่ใช้ติดตามความคืบหน้าของ task) และ delegate งานกลับไปให้แต่ละ app ทำ

🚢 Cargo Shipping — หลาย client 1 service layer

ระบบขนส่งของเรามี client หลายแบบที่เรียกใช้ความสามารถเดียวกัน: เจ้าหน้าที่หน้าเคาน์เตอร์จองผ่านเว็บ UI, ระบบของท่าเรือยิง message เข้ามาแจ้ง Handling Event เมื่อโหลด/ขนถ่ายตู้, และพาร์ทเนอร์เรียกผ่าน web service ทั้งสามเข้าทาง BookCargoService / HandlingEventService ชุดเดียวกัน — ถ้าวันหน้าเพิ่ม mobile app เข้ามา เราแค่ให้มันปรับตัวเข้าหา API เดิม ไม่ต้องแก้ domain เลย

สรุปประเด็นสำคัญ (The Salient Points)

DDD ไม่บังคับ สถาปัตยกรรมแบบใด — ขอเพียงแยก technical concern ออกจาก business concern ให้ขาดจากกัน
แยก concern ด้วยการ layer เพื่อ isolate ความซับซ้อนทางธุรกิจออกจากความซับซ้อนทางเทคนิค
ชั้นนอกพึ่งชั้นใน ส่วนชั้นในเปิด interface ให้ชั้นนอกมา implement — dependency inversion นี้คือกลไกที่ปกป้อง domain
domain layer อยู่ใจกลาง ถูก isolate จากเทคนิคโดยมี application layer ห่อหุ้มไว้
application service เปิดความสามารถของระบบโดยยก domain logic ขึ้นไปสู่ระดับ abstraction ที่สูงกว่า, อิงกับ use case, เป็น client ของ domain และ delegate งานให้ domain
application service ต้อง ไม่รู้จัก client — client เป็นฝ่ายปรับตัวเข้าหา API ทำให้รองรับ client ได้หลายแบบ
application service layer คือการ implement ขอบเขตของ bounded context อย่างเป็นรูปธรรม

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

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

Anti-Corruption Layer — ขยายความมุมมองที่ว่า application layer ทำตัวเป็นชั้นป้องกันไม่ให้รายละเอียดของ client ภายนอกไหลย้อนเข้ามาปนเปื้อน domain
Repository — รูปแบบที่ใช้อธิบายตัวอย่าง CargoRepository ในบทนี้ ซึ่งเป็นตัวอย่างคลาสสิกของ dependency inversion ระหว่าง domain กับ infrastructure
CQRS — ขยายความส่วน “Domain Reporting” ที่แยก read model ออกจาก transactional model
Anemic Domain Model — อธิบายผลลัพธ์ที่เกิดขึ้นเมื่อกฎธุรกิจรั่วไหลจาก domain layer เข้าไปอยู่ใน application service

เช็กความเข้าใจ — บทที่ 8

ข้อ 1 / 4

ตามหนังสือ DDD เรียกร้องอะไรจากสถาปัตยกรรมของ app?

Application Architecture — สถาปัตยกรรม​ที่​ปกป้อง domain model

แยก concern เพื่อ​ปกป้อง​ความ​ถูกต้อง​ของ model

Layered Architecture: domain อยู่​แกน​กลาง

Dependency Inversion: ทุก dependency ชี้​เข้า​ด้าน​ใน

สาม​ชั้น​ทำงาน​ร่วม​กัน​อย่างไร

Domain Layer — หัวใจ​ที่​ไม่รู้จัก​โลก​ภายนอก

Application Service Layer — façade ของ use case

Infrastructure Layers — รายละเอียด​ทาง​เทคนิค​ล้วนๆ

สื่อสาร​ข้าม​ชั้น​โดย​ไม่​ปล่อย domain object รั่ว

ทดสอบ​แยก​ส่วน​ได้ เพราะ​แยก concern แล้ว

อย่า share data schema ข้าม Bounded Context

สถาปัตยกรรม​ของ app ≠ สถาปัตยกรรม​ของ Bounded Context