จาก 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 แบบคือ
- จบในแต่ละ role หรือ domain ของตัวเอง ยกตัวอย่างเช่น โรงพยาบาลและโรงแรมเป็นต้น
- ต้องทำงานข้าม role หรือ domain ยกตัวอย่างเช่น การซื้อสินค้า เป็นต้น
ใน DDD นั้นจะแบ่ง domain ออกเป็น 3 กลุ่มคือ
- Core domains ส่วนการทำงานหลักที่เราให้ความสำคัญ และเราจะพูดคุยกันในส่วนนี้เป็นหลัก
- Generic domains ส่วนการทำงานที่เป็นมาตรฐาน สามารถซื้อระบบงานมาติดตั้งใช้งานได้เลย ช่วยลดเวลาในการ implement ลงไปอย่างมาก ใช้การจัดการมากกว่าการพัฒนา
- 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 ดังรูป
