บทนำ
เมื่อคุณเข้าใจ Domain-Driven Design ครบทั้ง Entity, Aggregate, Domain Service, Application Service, Repository และ Domain Event แล้ว
คำถามถัดไปที่เลี่ยงไม่ได้คือ:
แล้วเราควรจัดโครงสร้างระบบ (Architecture) แบบไหน ถึงจะทำให้ DDD ใช้งานได้จริงในระยะยาว?
บทความตอนนี้จะพาคุณทำความเข้าใจความสัมพันธ์ระหว่าง DDD กับสถาปัตยกรรมยอดนิยม 3 แบบ:
- Layered Architecture
- Clean Architecture
- Hexagonal Architecture
โดยอธิบายผ่านมุมมอง ระบบธุรกิจ / ระบบพนักงาน เช่นเดิม
DDD ไม่ใช่ Architecture แต่ต้องพึ่ง Architecture
สิ่งสำคัญที่ต้องเข้าใจก่อนคือ:
- DDD ไม่ใช่ framework
- DDD ไม่ใช่ architecture
- DDD คือ แนวคิดในการออกแบบ Domain
แต่ถ้าไม่มี architecture ที่เหมาะสม:
- Domain จะโดนเทคโนโลยีรุกล้ำ
- Business logic จะรั่วออกไปทุก layer
- DDD จะเหลือแค่ชื่อ
Layered Architecture – จุดเริ่มต้นที่คุ้นเคย
Layered Architecture แบ่งระบบออกเป็นชั้น ๆ เช่น:
Presentation
Application
Domain
Infrastructureข้อดี
- เข้าใจง่าย
- เหมาะกับทีมที่เริ่มใช้ DDD
- Mapping กับ DDD ได้ตรงไปตรงมา
ข้อจำกัด
- Dependency มักไหลผิดทิศ
- Domain เสี่ยงผูกกับ framework
- Test Domain แยกยากถ้า discipline ไม่ดี
Layered ใช้ได้ แต่ต้อง “เคร่ง” เรื่อง dependency
Clean Architecture – ปกป้อง Domain เป็นศูนย์กลาง
Clean Architecture วาง Domain และ Use Case ไว้ตรงกลาง
หลักการสำคัญ:
- Dependency ต้องชี้เข้าใน
- Domain ไม่รู้จักโลกภายนอก
- Framework เป็น detail
โครงสร้างเชิงแนวคิด:
Entities
Use Cases
Interface Adapters
Frameworks & Driversเหมาะกับ DDD อย่างไร
- Domain สะอาด
- Test ง่าย
- เปลี่ยน UI / DB ได้โดยไม่กระทบ Domain
ข้อแลกเปลี่ยนคือ:
- โครงสร้างซับซ้อนขึ้น
- ต้องเข้าใจ abstraction ดี
Hexagonal Architecture – โลกภายนอกเข้ามาทาง Port
Hexagonal Architecture (Ports & Adapters) มองระบบเป็นแกนกลางที่ถูกล้อมด้วย adapter
แนวคิดหลัก:
- Domain อยู่ตรงกลาง
- ติดต่อโลกภายนอกผ่าน Port
- Adapter เปลี่ยนได้โดยไม่กระทบ Domain
UI Adapter → Port → Application / Domain ← Port ← DB Adapterข้อดี
- แยก concern ชัดมาก
- เหมาะกับระบบที่มี integration เยอะ
- รองรับ event-driven architecture ได้ดี
ข้อจำกัด
- Conceptual overhead สูง
- ไม่เหมาะกับระบบเล็กมาก
แล้วควรเลือก Architecture แบบไหน
คำตอบคือ: ไม่มีแบบไหนดีที่สุดเสมอไป
แนวทางแนะนำ:
- ระบบเล็ก / ทีมใหม่ → Layered (แต่คุม dependency)
- ระบบธุรกิจจริง / scale ได้ → Clean หรือ Hexagonal
- ระบบที่ event-driven / integration หนัก → Hexagonal
สิ่งสำคัญไม่ใช่ชื่อ Architecture แต่คือการปกป้อง Domain
สรุป
- DDD ต้องการ Architecture ที่ปกป้อง Domain
- Layered, Clean และ Hexagonal ล้วนใช้กับ DDD ได้
- เลือกให้เหมาะกับบริบททีมและระบบ
- ถ้า Domain แข็งแรง Architecture จะเป็นพลัง ไม่ใช่ภาระ
ด้วยตอนที่ 10 นี้ แกนหลักของ DDD series ถือว่าครบถ้วนแล้ว
ถัดจากนี้ คุณสามารถต่อยอดไปสู่ DDD in Practice เช่น:
- Transaction & Consistency Boundary
- Eventual Consistency
- Refactoring Legacy System ด้วย DDD
SEO Meta (สำหรับ Yoast)
Focus Keyphrase: DDD Architecture
Meta Description:
Layered, Clean และ Hexagonal Architecture ต่างกันอย่างไร และแบบไหนเหมาะกับ Domain-Driven Design บทความนี้อธิบายการเลือก architecture เพื่อปกป้อง business logic และทำให้ DDD ใช้งานได้จริงในระบบธุรกิจ