จาก Part 1 เรื่องที่มาของ Domain-Driven Design (DDD)
ต่อมาใน Part 2 เป็นเรื่อง workshop การออกแบบตามแนวทาง DDD
แต่มีสรุปเรื่องของการออกแบบระบบงานใน class Domain-Driven Design แล้ว
ที่ blog สรุป Class Domain-Driven Design by Roofimon
ผมจึงทำการสรุปในมุมมองเล็ก ๆ น้อย ๆ ดีกว่า
เพื่อให้เห็นมุมมองในการออกแบบเพิ่มขึ้น

เริ่มจากทำความเข้าใจร่วมกันในงานที่จะทำ

หรือทำความเข้าใจกับปัญหา
จากนั้นทำการ modeling domain ต่าง ๆ ออกมา ประกอบไปด้วย

  • Strategic design
  • Tactical pattern

Model ที่ได้จากการออกแบบนั้น จะมีหลายรูปแบบได้
เพราะว่าไม่มี model ใดที่ดีที่สุด
แต่ในทุก ๆ model ล้วนมีประโยชน์

แสดงความแตกต่างระหว่าง Strategic design กับ Tactical pattern ดังรูป

เริ่มจาก Strategic Design กันเลย

ในการออกแบบเชิง Object-Oriented หรือ OOD นั้น

จะออกแบบหรือคิดส่วนการทำงานต่าง ๆ ในรูปแบบของ class/object
ส่วนในโลกของ DDD นั้นจะมองในรูปแบบของ Domain
และในแต่ละ domain จะมี Context มากกว่า 1
แต่ละ context ก็มีขอบเขตการทำงานที่ชัดเจน เรียกว่า Boundary Context
เป็นสิ่งที่ที่เราให้ความสนใจหรือเป็นสิ่งสำคัญนั่นเอง

ในระบบงานหนึ่ง ๆ มีส่วนการทำงานเยอะเหลือเกิน
ดังนั้นการที่จะเน้นไปเสียทุกส่วนจึงเป็นไปไม่ได้เลย (แต่เรามักจะทำกัน)
ผลที่ตามมาคือ ไม่มีอะไรดีสักอย่าง !!
ดังนั้นเราจำเป็นต้องเลือกว่า จะเริ่มทำความเข้าใจจากส่วนไหนก่อนหรือหลัง

ยกตัวอย่างดังรูป

ด้านซ้ายคือรูปโต๊ะอาหาร คือ Domain ที่เราสนใจ
ประกอบไปด้วยส่วนต่าง ๆ มากมาย
ทั้งอาหาร จาน ช้อนส้อม แก้วน้ำ โต๊ะ ผ้าปูโต๊ะ และอื่น ๆ อีกมากมาย
ทั้งหมดนี้คือ context สิ่งที่สนใจ

ดังนั้นอย่างแรกที่เราควรต้องทำคือ การ focus ไปยังส่วนที่สำคัญที่สุด
ถ้าในเชิงธุรกิจก็คือ ส่วนจะมีคุณค่าทาง business สูงสุดนั่นเอง


จากภาพจะให้ความสำคัญกับอาหาร นั่นก็คือ Pizza
ดังนั้นในตัวอย่าง สิ่งที่สนใจคือ Pizza 
ตรงนี้แหละคือ จุดเริ่มต้นของการออกแบบ
จากนั้นก็ได้เวลาเริ่มต้นการทำ workshop แล้ว

ใน workshop นั้นจำเป็นต้องมีผู้เชี่ยวชาญในด้านต่าง ๆ (Domain Expert)

ที่เกี่ยวกับ domain และ context นั้น ๆ
ประกอบไปด้วย Business Expert, Domain Expert
รวมไปถึงฝั่ง Implement หรือ Technical ด้วย
ในจุดนี้ผมมองว่า เป็นเรื่องที่สำคัญมาก ๆ
เพราะว่า ถ้าเราไม่มีผู้เชี่ยวชาญหรือทำในสิ่งนั้น ๆ มาพูดคุยด้วย
อาจทำให้ workshop หรือกระบวนการทำความเข้าใจผิดพลาดไปได้มากมาย

อีกอย่างใน workshop นี้มีคนมาจากหลาย ๆ ส่วนงาน
แน่นอนว่าความรู้ความเข้าใจแตกต่างกัน
ภาษาที่ใช้คุยก็ต่าง
ทำให้ยิ่งคุยยิ่งไม่รู้เรื่อง !!!

ยกตัวอย่างเช่น Business vs Technical มักจะใช้ภาษาพูดที่ต่างกัน
ยิ่งมาจากลุ่มอื่น ๆ อีกยิ่งไปกันใหญ่ 
ดังนั้นเราจำเป็นต้องมีภาษากลางที่ใช้สื่อสารกัน
ทาง DDD นั้นจะเรียกภาษากลางนี้ว่า “Obiquitous language”

จากหนังสือ The Anatomy of Domain-Driven Design
อธิบายได้ชัดเลยว่า
ต้องเน้นไปที่ domain term มากกว่า technical term นะ
แสดงดังรูป

ในขั้นตอนนี้ไม่ใช่การหา solution หรือวิธีการแก้ไขปัญหา (Solution space)

แต่เพื่อทำให้เราเข้าใจปัญหาหรือสิ่งที่ต้องการจริง ๆ (Problem space)
ในขั้นตอนนี้เราจะเริ่มจาก Problem space นั่นเอง แสดงดังรูป

ปัญหาใน workshop จะมี 2 แบบคือ

  1. จบในแต่ละ role หรือ domain ของตัวเอง ยกตัวอย่างเช่น โรงพยาบาลและโรงแรมเป็นต้น
  2. ต้องทำงานข้าม  role หรือ domain ยกตัวอย่างเช่น การซื้อสินค้า เป็นต้น

ใน DDD นั้นจะแบ่ง domain ออกเป็น 3 กลุ่มคือ

  1. Core domains ส่วนการทำงานหลักที่เราให้ความสำคัญ และเราจะพูดคุยกันในส่วนนี้เป็นหลัก
  2. Generic domains ส่วนการทำงานที่เป็นมาตรฐาน สามารถซื้อระบบงานมาติดตั้งใช้งานได้เลย ช่วยลดเวลาในการ implement ลงไปอย่างมาก ใช้การจัดการมากกว่าการพัฒนา
  3. Supporting domains เป็นส่วนที่ช่วยสนับสนุนการทำงาน สามารถให้ทีมที่มีประสบการณ์น้อย ๆ ทำได้ หรืออาจจะจ้าง outsource เข้ามาช่วยพัฒนา

จะให้ความสนใจหรือลงแรงไปยัง Core domain เป็นหลัก

ใน domain นั้นจะมี context หรือ boundary context มากกว่า 1 context
ดังนั้นแต่ละ context ต้องมีความสัมพันธ์กัน
สิ่งต่าง ๆ เหล่านี้เราจะเรียกว่า Context Map นั่นเอง
เพื่อเข้าใจความสัมพันธ์หรือความเกี่ยวข้องของแต่ละ context มากขึ้น


โดยมีรูปแบบต่าง ๆ ดังนี้ (แต่ละอย่างมันคืออะไรนะ ?) !!

  • Shared kernel
  • Customer/supplier teams
  • Conformist
  • Partnership
  • Anti-corruption layer (ACL)
  • Open-host service
  • Publish language
  • Separate ways

ตัวอย่างของการนำ Context map มาใช้แสดงดังรูป

เมื่อมาถึงตอนนี้ทำให้เราเข้าใจมากขึ้นว่า

  • มี Domain อะไรบ้าง
  • ในแต่ละ domain มี context อะไรบ้าง
  • แต่ละ context มีความสัมพันธ์ รวมทั้งแลกเปลี่ยนข้อมูลกันอย่างไร

โดยเราจะนำ model ที่ได้นี้ไปลงรายละเอียดต่อไป
นั่นก็คือ การนำ Tactical pattern มาใช้นั่นเอง
แต่ หมดแรงแล้ว เอาไว้เขียนต่อใน part ต่อไปดีกว่า !!

ก่อนจบ !!
แนวทางที่ทำมานี้ ไม่ได้บอกว่าจะถูกต้องและทำได้จริง

แต่มันคือแผนที่นำทาง
ซึ่งทุกคนที่เกี่ยวข้องสร้างมันมาจากความเข้าใจร่วมกัน
นั่นหมายความว่า
ทุกคนมองในภาพเดียวกัน
ดังนั้นถ้าผิดก็ผิดร่วมกัน หรือได้เรียนรู้ไปพร้อม ๆ กัน
ไม่ต้องมาเถียงกันว่าใครผิดหรือถูก

มันคือ วิธีการเรียนรู้ ลงมือทำ และรับ feedback เพื่อแก้ไขปรับปรุงให้ดีขึ้น
จนอาจจะทำให้เราได้แนวทางที่ถูกต้องและเหมาะสมกับเราในที่สุด
ยกตัวอย่างเช่น  Framework ของ Design Thinking ดังรูป