สรุปเรื่อง 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 : ไม่มีอะไรเชื่อมต่อกัน

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