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: การกระทำของฝ่ายต้นน้ำส่งผลต่อปลายน้ำ แต่ไม่ใช่ในทางกลับกัน ลองเลือกแต่ละรูปแบบในไดอะแกรมด้านล่างเพื่อดูความหมายและการเชื่อมต่อ
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 มีลักษณะอย่างไร?