Strategic Design
เมื่อ domain ใหญ่ขึ้น การสร้าง model เดียวที่ครอบทุกอย่างจะยากขึ้นต่อเนื่อง Evans บอกว่า “การรวม model ทั้งระบบให้เป็นหนึ่งเดียวมักไม่คุ้มและเป็นไปไม่ได้” ทางออกคือแบ่งเป็นเครือข่ายของ Bounded ContextBounded Contextขอบเขตที่ชัดเจน (มักเป็นระบบย่อยหรือทีมหนึ่ง) ที่ model หนึ่งใช้ได้และมีความหมายแน่นอน ภายในขอบเขตนี้ Ubiquitous Language สอดคล้องกัน 100%Strategic Design
Bounded Context — แก่นของ Strategic Design
หัวข้อที่มีชื่อว่า “Bounded Context — แก่นของ Strategic Design”Bounded ContextBounded Contextขอบเขตที่ชัดเจน (มักเป็นระบบย่อยหรือทีมหนึ่ง) ที่ model หนึ่งใช้ได้และมีความหมายแน่นอน ภายในขอบเขตนี้ Ubiquitous Language สอดคล้องกัน 100%Strategic Design คือการ “ลากเส้น” รอบบริเวณที่ model หนึ่งใช้ได้และมีความหมายแน่นอน — มักเป็นระบบย่อย ทีม codebase หรือ schema ฐานข้อมูลหนึ่ง ภายในเส้นนี้ Ubiquitous LanguageUbiquitous Languageภาษากลางที่ทุกคนในทีม (ทั้งนักพัฒนาและผู้เชี่ยวชาญธุรกิจ) ใช้ร่วมกัน อิงกับ domain model โดยตรง คำเดียวกันต้องหมายถึงสิ่งเดียวกัน และสะท้อนลงใน codeStrategic Design สอดคล้องกัน 100% ข้ามเส้นเมื่อไหร่ คำเดียวกันอาจเปลี่ยนความหมายได้ทันที
ใน context catalog “Product” คือชื่อ รูป คำอธิบาย ราคาตั้ง; ใน context คลังสินค้า “Product” คือ SKU น้ำหนัก ตำแหน่งจัดเก็บ; ใน context การจัดส่ง “Product” คือขนาดกล่องและน้ำหนักเพื่อคิดค่าส่ง — คนละ model แต่ชื่อเดียวกัน นี่คือเหตุผลที่ต้องมีขอบเขต
Subdomain — แบ่งตามคุณค่าทางธุรกิจ
หัวข้อที่มีชื่อว่า “Subdomain — แบ่งตามคุณค่าทางธุรกิจ”domain ใหญ่ถูกแบ่งเป็น SubdomainSubdomainส่วนย่อยของ Domain ใหญ่ เช่น Domain e-commerce แตกเป็น subdomain การสั่งซื้อ การชำระเงิน คลังสินค้า ฯลฯ อยู่ใน “พื้นที่ปัญหา” (problem space)Strategic Design ซึ่งอยู่ใน Problem SpaceProblem Space“พื้นที่ปัญหา” — สิ่งที่ธุรกิจต้องการแก้ไข อยู่ในรูปของ Domain และ Subdomain (ยังไม่พูดถึงวิธีแก้)Strategic Design และจัดระดับตามความสำคัญ:
- Core DomainCore Domainsubdomain ที่สำคัญและสร้างความได้เปรียบในการแข่งขันมากที่สุด เป็นเหตุผลที่เราต้องสร้างซอฟต์แวร์เองแทนการซื้อ ควรทุ่มทีมเก่งที่สุดลงตรงนี้Strategic Design — จุดที่สร้างความได้เปรียบ ต้องทำเองและทุ่มทีมเก่งที่สุด
- Supporting SubdomainSupporting Subdomainส่วนที่จำเป็นและเฉพาะกับธุรกิจเรา แต่ไม่ใช่จุดที่สร้างความได้เปรียบ ไม่มีของสำเร็จรูปที่พอดี จึงต้องทำเอง แต่ลงทุนน้อยกว่า coreStrategic Design — จำเป็นแต่ไม่ใช่จุดแข่งขัน ทำเองแบบลงทุนน้อย
- Generic SubdomainGeneric Subdomainปัญหาที่แก้กันมาแล้วทั่วไป เช่น ระบบ login บัญชี การแจ้งเตือน — ควรใช้ของสำเร็จรูปหรือ library แทนการเขียนเองStrategic Design — ปัญหาที่แก้กันมาแล้ว ใช้ของสำเร็จรูป (เช่น login, การจ่ายเงิน)
ซื้อของสำเร็จรูปมาใช้ได้โดยไม่เสียความได้เปรียบไหม? → Generic · ตรรกะธุรกิจง่ายไหม? → Supporting · ซื้อไม่ได้ และตรรกะซับซ้อน? → Core
การ “หาเส้นทางที่ดีที่สุด” (routing/optimization) มักเป็น Core DomainCore Domainsubdomain ที่สำคัญและสร้างความได้เปรียบในการแข่งขันมากที่สุด เป็นเหตุผลที่เราต้องสร้างซอฟต์แวร์เองแทนการซื้อ ควรทุ่มทีมเก่งที่สุดลงตรงนี้Strategic Design เพราะคือจุดที่สร้างความได้เปรียบ ส่วน “การออกใบแจ้งหนี้” เป็น supporting และ “การยืนยันตัวตนผู้ใช้” เป็น generic — ควรซื้อมาใช้
Domain vs Subdomain vs Bounded Context
หัวข้อที่มีชื่อว่า “Domain vs Subdomain vs Bounded Context”จุดที่สับสนที่สุดใน DDD สรุปคือ: SubdomainSubdomainส่วนย่อยของ Domain ใหญ่ เช่น Domain e-commerce แตกเป็น subdomain การสั่งซื้อ การชำระเงิน คลังสินค้า ฯลฯ อยู่ใน “พื้นที่ปัญหา” (problem space)Strategic Design อยู่ใน Problem SpaceProblem Space“พื้นที่ปัญหา” — สิ่งที่ธุรกิจต้องการแก้ไข อยู่ในรูปของ Domain และ Subdomain (ยังไม่พูดถึงวิธีแก้)Strategic Design (ปัญหาที่ธุรกิจมี) ส่วน Bounded ContextBounded Contextขอบเขตที่ชัดเจน (มักเป็นระบบย่อยหรือทีมหนึ่ง) ที่ model หนึ่งใช้ได้และมีความหมายแน่นอน ภายในขอบเขตนี้ Ubiquitous Language สอดคล้องกัน 100%Strategic Design อยู่ใน Solution SpaceSolution Space“พื้นที่คำตอบ” — วิธีที่เราเลือกแก้ปัญหา อยู่ในรูปของ Bounded Context และ model 1 subdomain อาจมีได้หลายคำตอบStrategic Design (วิธีที่เราเลือกแก้) อุดมคติคือจับคู่หนึ่งต่อหนึ่ง แต่ในความจริง1 subdomain อาจถูกทำเป็นหลาย context ได้ และในสถาปัตยกรรม microservices แต่ละ Bounded Context มักกลายเป็น1 service
Context Mapping — เก้ารูปแบบความสัมพันธ์
หัวข้อที่มีชื่อว่า “Context Mapping — เก้ารูปแบบความสัมพันธ์”เมื่อมีหลาย Bounded ContextBounded Contextขอบเขตที่ชัดเจน (มักเป็นระบบย่อยหรือทีมหนึ่ง) ที่ model หนึ่งใช้ได้และมีความหมายแน่นอน ภายในขอบเขตนี้ Ubiquitous Language สอดคล้องกัน 100%Strategic Design เราต้องนิยามว่าแต่ละคู่สัมพันธ์กันอย่างไร Context MapContext Mapแผนภาพที่แสดง Bounded Context ทั้งหมดและความสัมพันธ์ระหว่างกัน ช่วยให้เห็นภาพรวมและจุดเชื่อมต่อ/แปลภาษาในระบบใหญ่Strategic Design คือแผนภาพที่แสดงสิ่งนี้ เริ่มจากบทบาท Upstream/DownstreamUpstream / Downstreamความสัมพันธ์ที่การกระทำของฝ่ายต้นน้ำ (upstream) ส่งผลต่อฝ่ายปลายน้ำ (downstream) แต่ไม่ใช่ในทางกลับกัน — ทิศของอิทธิพลStrategic Design: การกระทำของฝ่ายต้นน้ำส่งผลต่อปลายน้ำ แต่ไม่ใช่ในทางกลับกัน ลองเลือกแต่ละรูปแบบในไดอะแกรมด้านล่างเพื่อดูความหมายและการเชื่อมต่อ
รูปแบบทั้งเก้ามีดังนี้ — ไดอะแกรมด้านล่างแสดงทิศทางของลูกศรและบทบาทของแต่ละฝ่ายให้ดูควบคู่กัน
- PartnershipPartnershipสองทีมที่หากฝ่ายใดล้มเหลวอีกฝ่ายก็ส่งงานไม่ได้ จึงต้องวางแผนและจัดการการเชื่อมต่อร่วมกัน feature ที่พึ่งพากันถูกจัดให้เสร็จใน release เดียวกันStrategic Design — สองทีมสำเร็จพร้อมกันและล้มพร้อมกัน จึงต้องวางแผนและปล่อยของด้วยกัน
- Shared KernelShared Kernelสองทีมตกลงแบ่ง model ส่วนเล็ก ๆ มาใช้ร่วมกันโดยมีขอบเขตชัดเจน ส่วนนี้ห้ามแก้โดยไม่ปรึกษากัน เพราะกระทบทั้งสองฝ่ายStrategic Design — แบ่ง model ก้อนเล็กก้อนหนึ่งมาใช้ร่วมกัน ฝ่ายเดียวแก้เองไม่ได้
- Customer/SupplierCustomer / Supplierความสัมพันธ์ที่ทีมต้นน้ำ (supplier) รับความต้องการของทีมปลายน้ำ (customer) เข้าไปวางแผนด้วย มีการเจรจาและจัดลำดับงานให้ชัดเจนStrategic Design — ต้นน้ำเป็นผู้ส่ง ปลายน้ำเป็นลูกค้าที่ต่อรองความต้องการของตัวเองได้
- ConformistConformistทีมปลายน้ำยอม “ตามใจ” model ของทีมต้นน้ำทั้งหมดเพื่อตัดความซับซ้อนในการแปลภาษา ใช้เมื่อทีมต้นน้ำไม่มีแรงจูงใจจะรองรับเราStrategic Design — ปลายน้ำยอมรับ model ของต้นน้ำทั้งดุ้น ไม่ต่อรองและไม่แปล
- Anticorruption LayerAnticorruption Layer (ACL)ชั้นกั้นที่ทีมปลายน้ำสร้างขึ้นเพื่อแปลง model ของระบบอื่นให้เป็นภาษาของ model ตัวเอง ป้องกันไม่ให้ model ภายนอกมา “ปนเปื้อน” model เราStrategic Design — ปลายน้ำสร้างชั้นแปลกั้นไว้ ไม่ให้ model ของต้นน้ำรั่วเข้ามาปนเปื้อน
- Open Host ServiceOpen Host Service (OHS)ทีมต้นน้ำเปิดบริการเป็นโพรโทคอล/API ที่นิยามไว้ชัดเจน ให้ทุกคนที่ต้องเชื่อมต่อมาใช้ได้ เหมาะกับระบบที่มีผู้ใช้หลายฝ่ายStrategic Design — ต้นน้ำเปิดบริการที่มีโพรโทคอลชัดเจนให้ผู้ใช้ทุกรายใช้เหมือนกัน
- Published LanguagePublished Languageภาษากลางที่จัดทำเป็นเอกสารชัดเจน ใช้เป็นสื่อแลกเปลี่ยนข้อมูลระหว่าง context เช่น มาตรฐานข้อมูลของอุตสาหกรรม มักใช้คู่กับ OHSStrategic Design — ทั้งสองฝ่ายตกลงใช้ภาษากลางที่เผยแพร่ไว้เป็นตัวแลกเปลี่ยนข้อมูล
- Separate WaysSeparate Waysประกาศว่า Bounded Context นี้ไม่เชื่อมต่อกับอันอื่นเลย เพื่อให้แต่ละฝ่ายหาทางแก้แบบง่าย ๆ เฉพาะของตน ใช้เมื่อค่าใช้จ่ายการเชื่อมต่อไม่คุ้มStrategic Design — ตัดสินใจไม่เชื่อมกันเลย เพราะต้นทุนของการเชื่อมสูงกว่าประโยชน์ที่ได้
- Big Ball of MudBig Ball of Mudระบบที่ปนเปกันยุ่งเหยิงไม่มีขอบเขตชัด ให้ลากเส้นล้อมไว้แล้วยอมรับสภาพ ไม่พยายามทำ model ละเอียดในนั้น และระวังไม่ให้ลามไป context อื่นStrategic Design — ไม่มีขอบเขต model ปนกันจนแยกไม่ออก รูปแบบนี้มีไว้ให้กัน ไม่ใช่ให้เลียนแบบ
Context Mapping — เลือกดูทั้ง 9 รูปแบบ
context mapEventStormingEventStormingเวิร์กช็อปแบบร่วมมือ (Alberto Brandolini, 2013) ใช้กระดาษโน้ตสีติดบนผนัง: ส้ม=event, น้ำเงิน=command, เหลือง=aggregate ฯลฯ เพื่อค้นพบ model และขอบเขตของ contextProcess (Alberto Brandolini, 2013) คือเวิร์กช็อปที่ใช้กระดาษโน้ตสีติดผนัง เริ่มจากไล่ “Domain EventDomain Eventสิ่งที่ “เกิดขึ้นแล้ว” ใน domain ซึ่งส่วนอื่นสนใจ แทนด้วยอ็อบเจ็กต์ที่เปลี่ยนแปลงไม่ได้ ตั้งชื่อเป็นอดีต เช่น CargoWasRouted ใช้สื่อสารข้าม AggregateTactical Design” (โน้ตสีส้ม เขียนเป็นอดีต) บนเส้นเวลา แล้วค่อยค้นพบ command, AggregateAggregateกลุ่มของ Entity และ Value Object ที่ถูกมองเป็นหนึ่งหน่วยเดียวเพื่อรักษาความถูกต้องของข้อมูล มีขอบเขตชัดเจน และเป็นหน่วยของ transactionTactical Design, policy ฯลฯ จุดที่แต่ละแผนกใช้ภาษาต่างกันสำหรับสิ่งคล้ายกัน มักเป็นรอยต่อของ Bounded ContextBounded Contextขอบเขตที่ชัดเจน (มักเป็นระบบย่อยหรือทีมหนึ่ง) ที่ model หนึ่งใช้ได้และมีความหมายแน่นอน ภายในขอบเขตนี้ Ubiquitous Language สอดคล้องกัน 100%Strategic Design พอดี
ลองวาด Context Map ของคุณเอง
หัวข้อที่มีชื่อว่า “ลองวาด Context Map ของคุณเอง”ด้านล่างคือกระดานจำลองแบบ EventStorming ลากกล่อง context ไปวางได้ตามใจ แล้วเชื่อมความสัมพันธ์โดยเลือกสองกล่องและกำหนดรูปแบบ ลองออกแบบแผนที่บริบทของระบบ e-commerce ดู
Bounded Contexts:
- Catalog
- Sales
- Payment
- Shipping
- Identity
ความสัมพันธ์ (Context Map):
| ต้นน้ำ | รูปแบบ | ปลายน้ำ |
|---|---|---|
| Sales | Customer/Supplier | Shipping |
| Sales | Anticorruption Layer | Payment |
Sales —[Customer / Supplier]→ Shipping · Sales —[ACL]→ Payment
สรุปภาพรวม Strategic Design
หัวข้อที่มีชื่อว่า “สรุปภาพรวม Strategic Design”- ขอบเขตที่ชัดเจน (มักเป็นระบบย่อยหรือทีมหนึ่ง) ที่ model หนึ่งใช้ได้และมีความหมายแน่นอน ภายในขอบเขตนี้ Ubiquitous Language สอดคล้องกัน 100%
- Ubiquitous Languageภาษากลางที่ทุกคนในทีม (ทั้งนักพัฒนาและผู้เชี่ยวชาญธุรกิจ) ใช้ร่วมกัน อิงกับ domain model โดยตรง คำเดียวกันต้องหมายถึงสิ่งเดียวกัน และสะท้อนลงใน code
- Context Mapแผนภาพที่แสดง Bounded Context ทั้งหมดและความสัมพันธ์ระหว่างกัน ช่วยให้เห็นภาพรวมและจุดเชื่อมต่อ/แปลภาษาในระบบใหญ่
- ส่วนย่อยของ Domain ใหญ่ เช่น Domain e-commerce แตกเป็น subdomain การสั่งซื้อ การชำระเงิน คลังสินค้า ฯลฯ อยู่ใน “พื้นที่ปัญหา” (problem space)
- Core Domainsubdomain ที่สำคัญและสร้างความได้เปรียบในการแข่งขันมากที่สุด เป็นเหตุผลที่เราต้องสร้างซอฟต์แวร์เองแทนการซื้อ ควรทุ่มทีมเก่งที่สุดลงตรงนี้
- Supporting Subdomainส่วนที่จำเป็นและเฉพาะกับธุรกิจเรา แต่ไม่ใช่จุดที่สร้างความได้เปรียบ ไม่มีของสำเร็จรูปที่พอดี จึงต้องทำเอง แต่ลงทุนน้อยกว่า core
- Generic Subdomainปัญหาที่แก้กันมาแล้วทั่วไป เช่น ระบบ login บัญชี การแจ้งเตือน — ควรใช้ของสำเร็จรูปหรือ library แทนการเขียนเอง
- กิจกรรมการระบุ Bounded Context และนิยามความสัมพันธ์ระหว่างกัน (เช่น Partnership, Shared Kernel, ACL) เพื่อจัดการการเชื่อมต่อระหว่างทีม/ระบบ
- Anticorruption Layerชั้นกั้นที่ทีมปลายน้ำสร้างขึ้นเพื่อแปลง model ของระบบอื่นให้เป็นภาษาของ model ตัวเอง ป้องกันไม่ให้ model ภายนอกมา “ปนเปื้อน” model เรา
- Open Host Serviceทีมต้นน้ำเปิดบริการเป็นโพรโทคอล/API ที่นิยามไว้ชัดเจน ให้ทุกคนที่ต้องเชื่อมต่อมาใช้ได้ เหมาะกับระบบที่มีผู้ใช้หลายฝ่าย
เจาะลึกแนวคิดในบทนี้ต่อได้ที่คลังอ้างอิง DevIQ:
- Bounded Context — นิยามและตัวอย่างการ “ลากเส้น” ขอบเขตที่ model หนึ่งใช้ได้ ตรงกับแก่นของบทนี้
- Subdomain — รายละเอียดการแบ่ง Core/Supporting/Generic Subdomain ตาม Problem Space
- Context Mapping — รูปแบบความสัมพันธ์ระหว่าง Bounded Context แบบละเอียดกว่าที่สรุปในไดอะแกรมด้านบน
- Anti-Corruption Layer — อธิบายชั้นป้องกัน model ที่ใช้ตอบคำถามควิซข้อสุดท้ายของบทนี้
- Event Storming — เทคนิคเวิร์กช็อปสำหรับค้นพบขอบเขต Bounded Context ที่กล่าวถึงในบทนี้
เช็กความเข้าใจ — Stage 2
ข้อ 1 / 4ภายใน Bounded Context 1 Ubiquitous Language มีลักษณะอย่างไร?