Strategic Design

เมื่อ domain ใหญ่ขึ้น การสร้าง model เดียวที่ครอบทุกอย่างจะยากขึ้นเรื่อย ๆ Evans บอกว่า “การรวมโมเดลทั้งระบบให้เป็นหนึ่งเดียวมักไม่คุ้มและเป็นไปไม่ได้” ทางออกคือแบ่งเป็นเครือข่ายของ Bounded ContextBounded Contextขอบเขตที่ชัดเจน (มักเป็นระบบย่อยหรือทีมหนึ่ง) ที่ model หนึ่งใช้ได้และมีความหมายแน่นอน ภายในขอบเขตนี้ Ubiquitous Language สอดคล้องกัน 100%Strategic Design

Bounded Context — แก่นของ Strategic Design

Bounded ContextBounded Contextขอบเขตที่ชัดเจน (มักเป็นระบบย่อยหรือทีมหนึ่ง) ที่ model หนึ่งใช้ได้และมีความหมายแน่นอน ภายในขอบเขตนี้ Ubiquitous Language สอดคล้องกัน 100%Strategic Design คือการ “ลากเส้น” รอบบริเวณที่ model หนึ่งใช้ได้และมีความหมายแน่นอน — มักเป็นระบบย่อย ทีม โค้ดเบส หรือสคีมาฐานข้อมูลหนึ่ง ภายในเส้นนี้ Ubiquitous LanguageUbiquitous Languageภาษากลางที่ทุกคนในทีม (ทั้งนักพัฒนาและผู้เชี่ยวชาญธุรกิจ) ใช้ร่วมกัน อิงกับ domain model โดยตรง คำเดียวกันต้องหมายถึงสิ่งเดียวกัน และสะท้อนลงในโค้ดStrategic Design สอดคล้องกัน 100% ข้ามเส้นเมื่อไหร่ คำเดียวกันอาจเปลี่ยนความหมายได้ทันที

🛒 คำว่า “Product” ในแต่ละ context

ใน context แคตตาล็อก “Product” คือชื่อ รูป คำอธิบาย ราคาตั้ง; ใน context คลังสินค้า “Product” คือ SKU น้ำหนัก ตำแหน่งจัดเก็บ; ใน context การจัดส่ง “Product” คือขนาดกล่องและน้ำหนักเพื่อคิดค่าส่ง — คนละโมเดล แต่ชื่อเดียวกัน นี่คือเหตุผลที่ต้องมีขอบเขต

Subdomain — แบ่งตามคุณค่าทางธุรกิจ

domain ใหญ่ถูกแบ่งเป็น SubdomainSubdomainส่วนย่อยของ Domain ใหญ่ เช่น Domain อีคอมเมิร์ซ แตกเป็น subdomain การสั่งซื้อ การชำระเงิน คลังสินค้า ฯลฯ อยู่ใน “พื้นที่ปัญหา” (problem space)Strategic Design ซึ่งอยู่ใน Problem SpaceProblem Space“พื้นที่ปัญหา” — สิ่งที่ธุรกิจต้องการแก้ไข อยู่ในรูปของ Domain และ Subdomain (ยังไม่พูดถึงวิธีแก้)Strategic Design และจัดระดับตามความสำคัญ:

• [[Core Domain]] — จุดที่สร้างความได้เปรียบ ต้องทำเองและทุ่มทีมเก่งที่สุด
• [[Supporting Subdomain]] — จำเป็นแต่ไม่ใช่จุดแข่งขัน ทำเองแบบลงทุนน้อย
• [[Generic Subdomain]] — ปัญหาที่แก้กันมาแล้ว ใช้ของสำเร็จรูป (เช่น ล็อกอิน, การจ่ายเงิน)

เกณฑ์ตัดสินใจ (Vladik Khononov)

ซื้อของสำเร็จรูปมาใช้ได้โดยไม่เสียความได้เปรียบไหม? → Generic · ตรรกะธุรกิจง่ายไหม? → Supporting · ซื้อไม่ได้ และตรรกะซับซ้อน? → Core

🚢 อะไรคือ Core ของบริษัทขนส่ง?

การ “หาเส้นทางที่ดีที่สุด” (routing/optimization) มักเป็น Core DomainCore Domainsubdomain ที่สำคัญและสร้างความได้เปรียบในการแข่งขันมากที่สุด เป็นเหตุผลที่เราต้องสร้างซอฟต์แวร์เองแทนการซื้อ ควรทุ่มทีมเก่งที่สุดลงตรงนี้Strategic Design เพราะคือจุดที่สร้างความได้เปรียบ ส่วน “การออกใบแจ้งหนี้” เป็น supporting และ “การยืนยันตัวตนผู้ใช้” เป็น generic — ควรซื้อมาใช้

Domain vs Subdomain vs Bounded Context

จุดที่สับสนที่สุดใน DDD สรุปง่าย ๆ คือ: [[Subdomain]] อยู่ใน [[Problem Space]] (ปัญหาที่ธุรกิจมี) ส่วน [[Bounded Context]] อยู่ใน [[Solution Space]] (วิธีที่เราเลือกแก้) อุดมคติคือจับคู่หนึ่งต่อหนึ่ง แต่ในความจริงหนึ่ง subdomain อาจถูกทำเป็นหลาย context ได้ และในสถาปัตยกรรม microservices แต่ละ Bounded Context มักกลายเป็นหนึ่ง service

---

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 map

PartnershipShared KernelCustomer / SupplierConformistACLOpen Host ServicePublished LanguageSeparate WaysBig Ball of Mud

Partnership: สองทีมที่หากฝ่ายใดล้มเหลวอีกฝ่ายก็ส่งงานไม่ได้ จึงต้องวางแผนและจัดการการเชื่อมต่อร่วมกัน ฟีเจอร์ที่พึ่งพากันถูกจัดให้เสร็จใน release เดียวกัน

EventStorming — เครื่องมือค้นพบขอบเขต

EventStormingEventStormingเวิร์กช็อปแบบร่วมมือ (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 ของคุณเอง

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

---

[quiz: เช็กความเข้าใจ — Stage 2 — coming soon]