สรุปเรื่อง Domain Driven Design ที่ AWS Thailand
พอดีทีมเราถูกส่งให้ไปเรียนเรื่อง Domain Driven Design ที่ AWS Thailand เพื่อที่จะได้เข้าใจเทคนิค DDD และสามารถนำมาประยุกต์ใช้กับ Component ของ AWS ได้อย่างเหมาะสม เลยอยากสรุปเอาไว้สักหน่อย
Understand the business Domain
- เข้าใจการทำงานของระบบ ระบุศัพย์ที่เข้าใจตรงกัน เข้าใจความหมายเท่ากัน
- เข้าใจ Ubiquitous Language (ศัพย์ท้องถิ่น) ของเราก่อน
- ต้องทำ เพราะคนเราประสบการณ์ไม่เท่ากัน ต้องทำความเข้าใจร่วมกันก่อน จะได้เข้าใจตรงกัน
Domain & Sub-Domain
- Domain : Key business domain
- Sub-Domain : Sub of overall business domain
Type of Subdomain
แต่ละทีม ควรแบ่งหน้าที่ของงานให้ชัดเจน ไม่ควรให้งานของแต่ละทีมซ้ำซ้อนกัน
Context Mapping
Kind of Mapping
- Partnership : 2 context อยู่ร่วมกัน ไม่มีใครใหญ่กว่าใคร ถ้าพังก็พังด้วยกัน ขาดกันไม่ได้
- Shared Kernel : มีส่วนที่ต้องแชร์กัน เน้นการ reuse context ถ้า change ส่วนนี้ context จะกระทบกัน ส่วนใหญ่ใช้ทีมเดียวกันทำ
- Customer-Supplier : supplier provider สิ่งที่ต้องการ customer เอาของไปใช้
- Conformist : supplier มี spec ชัดเจน customer ต้องทำตาม เช่น ไปเชื่อมต่อกับ platform เช่น ธนาคาร, line OA เราต้อง follow ตาม
- Anticorruption Layer : เหมือน Conformist แต่ทั้ง supplier และ customer มี spec ขัดเจน อาจจะต้องใช้ middleware มาช่วย
- Open Host Service : เปิด API ให้คนอื่นมาเอาข้อมูลไป
- Published Language : ฝั่ง supplier มีเอกสารชัดเจน customer มีหน้าที่ implement ตาม
- Separate Way : ไม่มีอะไรเชื่อมต่อกัน
What Is Domain-Driven Design?
Chapter 4. Context Mapping Not only does the bounded context pattern protect the consistency of a ubiquitous language, but it also enables modeling. You cannot build a model without specifying … - Selection from What Is Domain-Driven Design? [Book]
Tactical Design
Data Store
- Entity : มีสิ่งที่บอกว่าเป็น identity
- Aggregate : เป็นตัวเลือกว่าจะเอาข้อมูลแต่ละ entity มาทำการ aggregate กัน
- Value Object : เป็น object ที่เป็น value store ไม่มีสิ่งที่บอก identity
Aggregate Relationship
- ใช้ reference identity เท่านั้น
- ทำให้การอัพเดตไม่ต้องสนใจว่า อีกฝั่งจะมีข้อมูลหรือไม่
Domain Event
- เป็นการทำ message event ในการจัดการของ ส่วนใหญ่ใช้ในการ update ของ โดยตัว consumer ทำการ provide ของออกไป แล้วให้ subscriber เป็นคนเอาสิ่งนั้นไปทำต่อ
- เป็น business event ที่เกิดขึ้นในระบบไปแล้ว
Architectural Patterns
Layered Architecture
- Top-down communication model
- Each layer can only have dependency to underneath layer (ปกติแล้ว แต่ละ tier จะมี dependency ภายใต้ layer นั้นๆเท่านั้น เช่น ui → service → data ไม่งั้นจะกลายเป็น anti pattern เช่น ui → data)
Port and Adapter (Hexagonal Architecture)
- คล้ายๆ Layered Architecture
- เราจะ focus ตัว business logic เป็นหลัก
- ใช้ interface ในการคุยกันระหว่าง layer แทนการคุยกันตรงๆ
Event Souring
- เตรียม Aggregate Data
- แยกในส่วนที่ published กับ unpublished ออกจากกัน (outbox pattern) เพื่อแยกว่าส่วนไหนทำสำเร็จ อันไหนไม่สำเร็จ
- ควรเก็บข้อมูล event ที่เกิด event ว่าเป็นอย่างไรบ้าง
- ห้ามทำการแก้ไข event store ให้ subscription จาก message queue เท่านั้น
- ต้องเตรียมคิดทำ caching ด้วย หรือหากเยอะมาก ต้องทำ snapshot
Command Query Responsibility Segregation (CQRS)
- ในกรณีที่ไม่มี database ไหน ตอบโจทย์
- จะใช้ database ไหนก็ได้ ไม่จำเป็นต้องใช้ database เหมือนกับต้นทาง
- ต่อเนื่องจาก Event sourcing
- ระบบ replicate ของ database ใช้ pattern นี้อยู่
Event Driven Architecture (EDA)
- ระบบต่างๆ สื่อสารกันแบบ asynchronous
EDA x DDD
- Choreography between domains
- Orchestration within domain
- Event Consideration (Type of event)
- Domain Event : การกระทำที่เกิดจากการกระทำโดน Business
- Notification Event : เป็นการกระทำที่เกิดขึ้นเพื่อบอกบางสิ่งบางอย่างที่เกิดขึ้น (แจ้งเพื่อทราบ)
- Event Carried State : เป็นการกระทำที่เกิดขึ้นเพื่อบอกบางสิ่งที่เป็นการบอกถึง state ที่เปลี่ยนไป (แจ้งรายละเอียดด้วย)
- Event-Driven Design Considerations
- ทุกอย่างมีสิทธิ์จะ fail ให้คุณคิดว่ามันมีโอกาสจะ fail เสมอ
- ให้คุณคิดหา solution ที่จะแก้ปัญหาที่เกิดขึ้นเสมอ เช่น ข้อความอาจจะได้รับไม่เรียงกัน ข้อความอาจจะไปไม่ถึง
DDD AWS Solution
