ไปเจอ Domain Message Flow Diagram มาน่าสนใจดีเป็น diagram สำหรับการออกแบบ flow ของ messageที่ใช้ติดต่อสื่อสาร หรือ แลกเปลี่ยนระหว่าง actor, boundary context หรือ service/system ก็ว่าไปเพื่อช่วยให้ทีมที่เกี่ยวข้องเข้าใจได้ง่ายยิ่งขึ้นเป็นอีกรูปแบบหนึ่งของการพูดคุยบนภาษาเดียวกัน
สิ่งหนึ่งที่มักได้ยินบ่อย ๆ ในการพัฒนา software คือ เรื่องของ Event-based Architecture ยิ่งมีการพูดถึงมาก ๆ ในแนวคิดของ microservices ตามจริงก็พูดกันเยอะมาก ๆ จาก Domain-Driven Design ในเรื่อง Strategic design (Integration pattern) อ่านเจอบทความเรื่อง Best Practices for Event-Driven Microservice ซึ่งอธิบายได้อย่างน่าสนใจ ประกอบไปด้วย Event-based Architecture คืออะไร ? ทำไมถึงต้องใช้ด้วย ? Event-based Architecture มีข้อดีและแน่นอนว่ามีข้อเสียอะไรที่ต้องรับมือ ? จึงทำการสรุปไว้นิดหน่อย
จากการพูดคุยเรื่องของ Event-based architecture นั้น มักจะเจอ 2 คำคือ Domain Event Event Sourcing คำถามที่น่าสนใจคือมันคืออะไร ? ทำหน้าที่อะไรกันแน่ ก็เลยทำการอธิบายแบบสั้น ๆ ไว้หน่อย
ในระบบงานหนึ่ง ๆ นั้นมักจะซับซ้อนเสมอ มี context หรือส่วนการทำงานจำนวนมาก ดังนั้นจำเป็นต้องแยกและกำหนดกรอบทำงานที่ชัดเจนให้แต่ละ context หรือเรียกว่า Boundary context แต่ปัญหาที่เกิดตามมาก็คือ แต่ละ Boundary context จะต้องติดต่อสื่อสาร หรือต้องทำการแลกเปลี่ยนข้อมูลกัน หรือเรียกว่าความสัมพันธ์ระหว่าง Boundary context กันอย่างไร
จาก Part 1 เรื่องที่มาของ Domain-Driven Design (DDD)ต่อมาใน Part 2 เป็นเรื่อง workshop การออกแบบตามแนวทาง DDD แต่มีสรุปเรื่องของการออกแบบระบบงานใน class Domain-Driven Design แล้ว ที่ blog สรุป Class Domain-Driven Design by Roofimonผมจึงทำการสรุปในมุมมองเล็ก ๆ น้อย ๆ ดีกว่า เพื่อให้เห็นมุมมองในการออกแบบเพิ่มขึ้น
พอดีช่วงบ่ายวันศุกร์เห็น course Domain-Driven Design by Roofimon เด้งขึ้นมาลองไปกดดู ก็มีบัตรว่างด้วย ดังนั้นจึงซื้อตั๋วไปเรียนด้วย เป้าหมายหลัก ๆ เพื่อทำให้รู้และเข้าใจเกี่ยวกับ DDD (Domain-Driven Design) ว่าคืออะไร เป็นอะไร มาเริ่มกันเลย