กลั่น problem domain ออกมา

บทที่แล้วเราเห็นว่า DDD แยกการแก้ปัญหาออกเป็น problem space และ solution space บทนี้เจาะลงไปที่ครึ่งแรก — เราจะ “เข้าใจ” problem domain ที่ซับซ้อนได้อย่างไร ก่อนจะลงมือเขียน code แม้แต่บรรทัดเดียว

หัวใจของคำตอบคือคำว่า Knowledge Crunching — “การบดเคี้ยวความรู้” ร่วมกับคนที่เข้าใจธุรกิจอย่างแท้จริง การพิมพ์ code ไม่เคยเป็นส่วนที่ยากที่สุด ส่วนที่ยากคือการกลั่นความรู้มหาศาลใน domain ออกมาให้เหลือเฉพาะ สิ่งที่สำคัญต่อการแก้ปัญหา แล้วหล่อมันลงเป็น model ที่ใช้ได้จริง

Knowledge Crunching คืออะไร

Domain ที่ซับซ้อนเต็มไปด้วยข้อมูล ส่วนใหญ่ของข้อมูลนั้น ไม่เกี่ยวข้อง กับปัญหาที่เรากำลังแก้ และจะคอยรบกวนสมาธิในการสร้าง model Knowledge Crunching คือศิลปะของการกลั่นเอาเฉพาะข้อมูลที่ “เกี่ยวข้อง” ออกมา เพื่อสร้าง model ที่ตอบโจทย์ business use case ได้

มันคือสะพานที่ปิดช่องว่างความรู้ระหว่างทีมเทคนิคกับธุรกิจ และจะเกิดขึ้นได้ก็ต่อเมื่อทำงาน ร่วมกัน กับคนที่เข้าใจ domain มากที่สุด — ผู้ใช้ตัวจริง ผู้มีส่วนได้ส่วนเสีย และผู้เชี่ยวชาญเฉพาะด้าน หากขาดสิ่งนี้ เรามักได้โซลูชันทางเทคนิคที่ “ปราศจาก insight ของธุรกิจ” — code ที่ทำงานได้แต่ไม่มีใครเข้าใจเมื่อต้องดูแลรักษาต่อ

ดังรูปที่ 2-1 กระบวนการเริ่มจาก กระบวนการธุรกิจ (business process) ทีมเดินผ่าน use case/story/scenario ร่วมกับธุรกิจบนกระดานไวต์บอร์ด ค่อยๆ ทำให้ model “ง่ายลง” เมื่อเข้าใจ problem domain มากขึ้น จนได้ model ที่ใช้แก้ปัญหาได้จริง

รูปที่ 2-1: วงจร Knowledge Crunching — เริ่มจาก business use case นำความรู้จาก business expert และทีมพัฒนามาบดเคี้ยวร่วมกัน แล้วกลั่นออกมาเป็น model ที่ตอบโจทย์ use case และทำให้ง่ายขึ้นเมื่อเข้าใจมากขึ้น

หัวใจของ Knowledge Crunching

ความรู้ใน domain สำคัญยิ่งกว่าความรู้ทางเทคนิค ทีมต้องดำดิ่งลงไปใน problem domain แล้วซึมซับความรู้ราวกับฟองน้ำ ถ้าคุณยังอธิบายแนวคิดที่ซับซ้อนของธุรกิจให้ผู้ใช้เข้าใจด้วยภาษาเรียบง่ายไม่ได้ ก็แสดงว่าคุณยังไม่พร้อมจะลงมือเขียนซอฟต์แวร์ใน domain นั้น

ภาษากลางคือผลผลิตของการร่วมมือ

ผลลัพธ์สำคัญอย่างหนึ่งของ Knowledge Crunching คือ Ubiquitous Language (UL) — ภาษากลางที่อุดมไปด้วยศัพท์เฉพาะของ domain เมื่อสร้าง model ร่วมกับผู้เชี่ยวชาญ ทุกคนต้องตั้งใจใช้คำชุดเดียวกันให้สม่ำเสมอ ทั้งตอนอธิบาย model ตอนคุยกัน และที่สำคัญ — ตอนเขียน code คำเดียวกันต้องไปปรากฏเป็นชื่อ class ชื่อ property และชื่อ method

UL ผูก “model ใน code” เข้ากับ “model เชิงแนวคิด” ที่ธุรกิจเข้าใจ ทำให้เราไม่ต้องคอยแปลไปมาระหว่าง model ทางเทคนิคกับ model ทางธุรกิจ — ซึ่งทุกครั้งที่แปล insight สำคัญย่อมมีโอกาสหลุดหายไป (เราจะลงลึกเรื่อง UL ในบท Model-Driven Design)

🚢 ฟัง “คำ” ของคนขนส่ง

ใน session Knowledge Crunching กับบริษัทขนส่ง คุณจะได้ยินคำว่า “จอง (book) การขนส่ง” “วางแผนเดินทาง (itinerary)” “ขา (leg) การขนส่งแต่ละช่วง” “บันทึกการจัดการ (handling) ที่ท่าเรือ” คำเหล่านี้ไม่ใช่ศัพท์ที่เราคิดเอง แต่เป็นภาษาที่พนักงานใช้กันจริง — มันคือเมล็ดพันธุ์ของ Ubiquitous Language ที่จะกลายเป็น Cargo, Itinerary, Leg, HandlingEvent ใน code ต่อไป

บทบาทของ Business Analyst ยังจำเป็นไหม?

ยังจำเป็น BA ช่วยให้ผู้มีส่วนได้ส่วนเสียขยายไอเดียตั้งต้น และเก็บ input/output ของระบบได้ และถ้านักพัฒนาเขินอายไม่กล้าคุยกับ domain expert ก็ใช้ BA เป็นผู้อำนวยความสะดวก (facilitator) ได้ สิ่งที่ ต้องไม่ทำ คือเอา BA มาคั่นกลางจนตัดขาดการสื่อสารโดยตรงระหว่างทีมพัฒนากับคนที่เข้าใจธุรกิจมากที่สุด

domain expert ต่างจาก stakeholder อย่างไร

DDD เรียกผู้เชี่ยวชาญเฉพาะด้านว่า domain expert — คนที่เข้าใจธุรกิจตั้งแต่นโยบาย กระบวนการ ไปจนถึงข้อยกเว้นปลีกย่อยที่ไม่มีในเอกสาร พวกเขาแทบไม่เคยมีตำแหน่งว่า “domain expert” ตรงๆ ให้มองหา product owner ผู้ใช้ตัวจริง หรือใครก็ตามที่เข้าใจ domain นี้ลึกที่สุด ไม่ว่าจะมีตำแหน่งใดก็ตาม

รูปที่ 2-2 ชี้ความต่างชัดๆ: stakeholder บอกว่าระบบ “ควรทำอะไร” — พวกเขาโฟกัสที่ input และ output (นี่คือ problem space: ความต้องการ) ส่วน domain expert ทำงานกับเราเพื่อสร้าง model ที่ตอบโจทย์นั้นได้ (นี่คือ solution space)

รูปที่ 2-2: บทบาทสามฝ่าย — stakeholder + ทีมพัฒนาสื่อสารเป้าหมายและ input/output ออกมาเป็น business use case แล้ว domain expert + ทีมพัฒนา crunch ความรู้ร่วมกันจนได้ model ที่ตอบโจทย์ use case นั้น

การทำงานกับ domain expert ไม่ได้ช่วยแค่ทีมพัฒนา แต่ยังช่วยให้ตัว domain expert เอง “จับต้อง” ความเข้าใจของตัวเองได้ชัดขึ้น แนวคิดที่ธุรกิจเคยเข้าใจกันแบบ implicit จะถูกนิยามออกมาเป็นคำที่ชัดเจน ทำให้การสื่อสารภายในธุรกิจดีขึ้นด้วย

Knowledge Crunching เป็นกระบวนการต่อเนื่อง ไม่ใช่ทำครั้งเดียวจบ

การร่วมมือกับธุรกิจไม่ควรจำกัดอยู่แค่ช่วงเริ่ม project insight ที่ลึกซึ้งและการ “ทะลุกรอบ” แบบ design breakthrough มักเกิดขึ้นหลังจากใช้ชีวิตคลุกคลีอยู่กับปัญหาผ่านหลาย iteration model ไม่มีคำว่าสมบูรณ์แบบ มีเพียง model ที่ตอบโจทย์ปัญหา ณ ขณะนี้เท่านั้น ทุก iteration ความต้องการใหม่ย่อมเข้ามา และ model ต้องวิวัฒน์ตาม

เทคนิคกลั่นความรู้ให้ได้ผล

การสร้าง model เป็นงานที่ต้องอาศัยความร่วมมือ แต่ผู้ใช้ฝั่งธุรกิจมักมีงานรัดตัวและอาจรู้สึกว่ามันน่าเบื่อ เราจึงต้องทำให้ session สนุกและชวนให้มีส่วนร่วม ต่อไปนี้คือเทคนิคที่ DDD practitioner ใช้กัน

โฟกัสบทสนทนาที่น่าสนใจที่สุด

อย่าไล่อ่าน requirement ทีละข้อให้ domain expert ฟังจนเบื่อ เวลาของพวกเขามีค่า ให้เริ่มจากส่วนที่ “ทำให้ธุรกิจนอนไม่หลับ” — ส่วนที่เป็น core ต่อความสำเร็จของระบบ ลองถามว่าส่วนไหนของระบบปัจจุบันใช้งานยาก งานที่ต้องทำด้วยมือแบบไหนที่ขัดขวางไม่ให้เขาไปสร้างคุณค่าได้ หรืออะไรจะช่วยเพิ่มรายได้/ลดต้นทุน เคล็ดลับคือ “ตามเงินไป” (follow the money)

เริ่มจาก use case แล้วถามคำถามทรงพลัง

วิธีที่ดีที่สุดในการเข้าใจ domain ใหม่คือการวาด use case ออกมาเป็นขั้นๆ ฟังหา domain terminology ระหว่างนั้น เพราะมันคือจุดเริ่มของภาษากลาง อย่ารีบกระโดดไปหา solution ก่อนเข้าใจปัญหาจริงๆ และอย่าลืมถามคำถามที่เปิดเผย “เจตนา” เบื้องหลัง เช่น

ความต้องการระบบนี้มาจากไหน?
ระบบนี้จะสร้างคุณค่าให้ธุรกิจอย่างไร?
ถ้าไม่สร้างระบบนี้ จะเกิดอะไรขึ้น?

Greg Young — powerful questions

Greg Young มีบทความชื่อดังเรื่อง “powerful questions” ที่รวมตัวอย่างคำถามดีๆ ซึ่งช่วยปลดล็อกความรู้ใน domain ออกมาได้ — คำถามที่ถูกต้องมีค่ามากกว่าคำตอบที่รีบเร่ง

Sketching และ CRC cards

คนเรามักเข้าใจได้เร็วขึ้นเมื่อเห็นภาพ การวาด sketch ง่ายๆ บนไวต์บอร์ดช่วยเร่ง session ได้มาก หลักสำคัญข้อเดียวคือ คุมระดับรายละเอียด (granularity) ให้อยู่ในระนาบเดียวกัน — ถ้ากำลังคุยภาพใหญ่ว่าระบบสื่อสารกันอย่างไร ก็อย่าหลุดลงไปถึงระดับชื่อ class และอย่าใช้เครื่องมือทางการอย่าง Visio/UML ที่ละเอียดเกินไปสำหรับ session ที่ต้องลองผิดลองถูกหลายรอบ — เพราะคุณจะ “เสียดาย” ไดอะแกรมที่ลงแรงวาดทั้งเช้า มากกว่า sketch ที่ใช้เวลาเพียงนาทีเดียว

อีกเครื่องมือคือ CRC card (Class-Responsibility-Collaboration) แต่ละใบบันทึกสามส่วน: ชื่อ class (แทนแนวคิดใน domain), หน้าที่ของมัน, และ class อื่นที่ต้องทำงานด้วย — ดึงให้ทีมและธุรกิจคิดในรูปของ “ภาษา” ของแนวคิด

เลื่อนการตั้งชื่อออกไปก่อน

การตั้งชื่อเร็วเกินไปเป็นกับดัก เพราะคำที่เลือกจะ “ครอบงำ” วิธีคิดของคุณ จนเมื่อ crunch ความรู้เพิ่มแล้วพบว่าแนวคิดไม่ตรงกับชื่อ ก็เปลี่ยนได้ยาก Greg Young แนะนำให้ใช้คำที่ไม่มีความหมาย (gibberish) หรือใช้สีแทนชื่อจริงไปก่อน จนกว่าจะเข้าใจหน้าที่และข้อมูลของมันครบถ้วน และ พึงระวังชื่อที่ว่างเปล่าอย่าง XxxService หรือ XxxManager — หากเผลอจะเติม “Service/Manager” ให้กลับมาคิดใหม่ และมองหาเจตนาที่แท้จริงเบื้องหลังชื่อนั้น

BDD — ขับเคลื่อนด้วยพฤติกรรม

Behaviour-Driven Development (BDD) เป็นกระบวนการที่ต่อยอดจาก TDD โดยโฟกัสที่การจับ พฤติกรรมของระบบ (system behaviour) แล้วขับเคลื่อนการออกแบบจากภายนอกเข้าสู่ภายใน ความต่างจาก DDD คือ BDD โฟกัสว่า “ระบบควรทำงานอย่างไร” ส่วน DDD โฟกัสที่ domain model ใจกลางซึ่งทำให้พฤติกรรมนั้นเป็นจริงได้ — ต่างกันเพียงเล็กน้อยแต่สำคัญ

BDD มีรูปแบบภาษาเฉพาะคือ GWT (Given–When–Then) ที่ช่วยจัดโครงสร้างบทสนทนากับ domain expert และเผยพฤติกรรมที่แท้จริงของ domain ออกมา feature แต่ละตัวอธิบายพฤติกรรมที่ส่งมอบคุณค่าต่อธุรกิจ พร้อมระบุ “บทบาท” (ใคร) และ “ประโยชน์” (ทำไม)

🛒 BDD scenario — ส่งฟรีเมื่อยอดถึงเกณฑ์

ลองดู feature “ส่งฟรีสำหรับคำสั่งซื้อยอดสูง” เขียนเป็น scenario แบบ GWT:

Feature: ส่งฟรีสำหรับคำสั่งซื้อยอดสูง

Scenario: ลูกค้ายอดถึงเกณฑ์ส่งฟรี
  Given เกณฑ์ส่งฟรีตั้งไว้ที่ 60 บาท
  And ฉันมีตะกร้ารวม 50 บาท
  When ฉันเพิ่มสินค้าราคา 11 บาทลงตะกร้า
  Then ฉันควรได้รับสิทธิ์ส่งฟรี

scenario แบบนี้ทำหน้าที่สองอย่าง: เป็น acceptance criteria ที่ dev/tester ใช้ระบุว่า feature เสร็จสมบูรณ์เมื่อใด และเป็นเครื่องยืนยันว่าทีม “เข้าใจตรงกัน” กับธุรกิจ — ทั้งยังตอกย้ำ domain language ไปในตัว

Rapid prototyping และ “code as analysis”

ผู้ใช้ฝั่งธุรกิจมักชอบเห็น mock-up หน้าจอมากกว่าอ่านเอกสาร เพราะมันเผยเจตนาเบื้องหลังได้ชัดเจนกว่า อีกรูปแบบหนึ่งคือสิ่งที่ Greg Young เรียกว่า “code as analysis” — เขียน code เพื่อจับ requirement สดๆ ต่อหน้าธุรกิจ การลงมือเขียนช่วยให้ session โฟกัส พิสูจน์ model และหลีกเลี่ยง analysis paralysis (อาการจมอยู่กับการคิดเชิงนามธรรมจนไม่ลงมือทำ)

code ที่เขียนตอนวิเคราะห์คือ code สำหรับโยนทิ้ง (throw-away code)

จงสร้าง code model เฉพาะส่วนที่เกี่ยวข้องและอยู่ใน context ที่กำลังแก้ เท่านั้น — เราไม่อาจจำลองทั้ง domain ได้ ให้คิดทีละส่วนเล็กๆ สร้างรอบๆ กฎ แล้วค่อยต่อยอด ที่สำคัญ: นี่คือ code สำหรับโยนทิ้ง (throw-away code) อย่าหยุดอยู่ที่ model แรกที่พอใช้ได้ และอย่ายึดติดกับไอเดียดีๆ อันแรกจนเกินไป

นอกจากนี้อย่ามองข้ามระบบกระดาษ (paper-based) ที่ใช้อยู่ — ภาษาที่ธุรกิจใช้ในนั้นมีคุณค่า และบาง edge case ที่พบนานๆ ครั้ง อาจคุ้มกว่าถ้า “คืนอำนาจ” ให้กระบวนการที่ทำด้วยมือ แทนที่จะลงแรงสร้าง model ซับซ้อนเพื่อรองรับมัน

มองหา model ที่มีอยู่แล้ว — อย่าคิดล้อใหม่

ถ้าทำงานใน domain ที่มีมายาวนาน (เช่น สถาบันการเงิน) มีความเป็นไปได้สูงว่ามี model มาตรฐานอยู่แล้ว หนังสือ Analysis Patterns ของ Martin Fowler รวบรวม model ทั่วไปในหลาย domain ที่ใช้เป็นจุดตั้งต้นได้ และในองค์กรเองก็อาจมี process map/workflow เดิมอยู่ — ลองขอมาดู แล้วสร้าง knowledge base (เช่น wiki) เก็บคำและนิยามไว้ใช้ร่วมกันในทีม

EventStorming — เวิร์กช็อปค้นพบ domain

EventStorming เป็นกิจกรรมเวิร์กช็อปที่ Alberto Brandolini คิดขึ้น เพื่อสร้างความเข้าใจ problem domain อย่างรวดเร็วและสนุก โดยให้ domain expert (ผู้มีคำตอบ) กับทีมพัฒนา (ผู้มีคำถาม) มาทำงานร่วมกันในพื้นที่เปิดโล่งที่มีผนัง/กระดาษยาวๆ ช่วยกันสร้างแบบจำลองให้เห็นภาพร่วมกันด้วยตาเปล่า

วิธีคือเริ่มจาก Domain Event — เหตุการณ์ที่ธุรกิจให้ความสนใจซึ่งเกิดขึ้นใน domain ติด post อิตสีส้มแทน event แล้วถามว่าอะไรเป็นตัวกระตุ้น: อาจเป็น command จากการกระทำของผู้ใช้ (สีน้ำเงิน) หรือระบบภายนอก/event อื่น ทำซ้ำไปจนไม่เหลือคำถาม จากนั้นจึงสร้าง model รอบๆ จุดตัดสินใจ จุดเด่นคือทุก event และ command ถูกตั้งชื่ออย่างชัดเจน จึงช่วยปั้น UL ได้ดีมาก และยังเผย Subdomain กับ Core Domain ออกมาให้เห็น (รายละเอียดในบทถัดไป)

flowchart LR
  C["command<br/>(สีน้ำเงิน)<br/>BookCargo"] --> A["aggregate<br/>(สีเหลือง)<br/>Cargo"]
  A --> E["domain event<br/>(สีส้ม)<br/>CargoWasBooked"]
  E --> P["policy/reaction<br/>เมื่อจองแล้ว<br/>ต้องวาง itinerary"]
  P --> C2["command<br/>AssignRoute"]

🚢 EventStorming ระบบขนส่ง

ติดบนผนัง: CargoWasBooked → RouteWasAssigned → CargoWasLoaded → CargoWasUnloaded → CargoWasClaimed เมื่อเรียง domain event เป็นเส้นเวลา ทีมจะเห็นทันทีว่า “การจอง” กับ “การจัดการจริงที่ท่าเรือ (handling)” เป็นคนละเรื่องที่อาจอยู่คนละ subdomain — insight แบบนี้หาได้ยากมากหากเพียงนั่งอ่าน requirement เฉยๆ

เข้าใจเจตนาและ model ธุรกิจ

พึงระวังลูกค้าที่ขอ “ปรับปรุง” ระบบเดิม เพราะพวกเขามักให้ requirement ที่อิงข้อจำกัดของระบบปัจจุบัน ไม่ใช่สิ่งที่ต้องการอย่างแท้จริง ให้ถามหา “ทำไม” ที่อยู่เบื้องหลัง “อะไร” เสมอ คุณคือ enabler — อย่าทำตาม requirement อย่างหลับหูหลับตา แต่จงเข้าใจวิสัยทัศน์ที่ธุรกิจพยายามจะไปให้ถึง เพื่อจะเสนอทางที่ดีกว่าได้

Impact Mapping เป็นเทคนิคที่ช่วยในจุดนี้ แทนที่จะเริ่มจากเอกสาร requirement เราเริ่มจาก “ผลกระทบ (impact)” ที่ธุรกิจอยากสร้าง เช่น “เพิ่มยอดขายจักรยาน 25%” แล้วแตกออกเป็นชั้นๆ: ใคร (actor) ที่ช่วยได้ → เขาช่วยได้อย่างไร → งานจริงที่ลงมือทำ ดังรูปที่ 2-3 มันคือ mind map ที่ทำร่วมกับธุรกิจ ช่วยให้เราตั้งคำถามได้คมขึ้นเพราะรู้ชัดว่าธุรกิจต้องการอะไร

รูปที่ 2-3: Impact map ตัวอย่าง — เริ่มจากผลกระทบ “ขายจักรยานเพิ่ม 25%” แตกไปยัง actor (Developers, Data Scientists) แล้วแตกต่อเป็นวิธีที่แต่ละฝ่ายช่วยได้ และงานจริงที่ลงมือทำ

อีกเครื่องมือคือ Business Model Canvas ของ Alexander Osterwalder ที่ย่อย model ธุรกิจออกเป็น 9 ช่อง (รูปที่ 2-4) ตั้งแต่ลูกค้าเป้าหมาย คุณค่าที่ส่งมอบ ช่องทาง ไปจนถึงโครงสร้างต้นทุนและช่องทางรายได้ — นักพัฒนาน้อยคนนักที่จะลงทุนเวลาทำความเข้าใจ model ธุรกิจของนายจ้างตัวเอง ทั้งที่มันบอกชัดว่า “อะไรสำคัญต่อธุรกิจ” และช่วยให้เราตั้งคำถามที่มีความหมายต่อ domain expert ได้

รูปที่ 2-4: Business Model Canvas ของร้านอุปกรณ์กีฬาออนไลน์ — แบ่ง model ธุรกิจเป็น 9 ส่วน ตั้งแต่ Key Partners, Value Propositions ไปจนถึง Cost Structure และ Revenue Streams

Deliberate Discovery และ Model Exploration Whirlpool

Dan North (ผู้คิด BDD) เสนอ Deliberate Discovery — แทนที่จะหมกมุ่นกับพิธีกรรมของ agile อย่าง planning poker ให้ทุ่มเวลาเรียนรู้ส่วนของ domain ที่เรา “ไม่รู้” เขากล่าวว่า “ความไม่รู้คืออุปสรรคใหญ่ที่สุดของ throughput” ตั้งแต่เริ่ม project ทีมควรตั้งใจค้นหาว่า unknown unknowns อยู่ตรงไหน แล้วจัดการมันให้เร็วใน session Knowledge Crunching

ส่วน Eric Evans เสนอ Model Exploration Whirlpool — ไม่ใช่ระเบียบวิธีสร้าง model แต่เป็นสิ่งที่หยิบมาใช้ “เมื่อเจอปัญหา” ระหว่างสร้าง model (เช่น สื่อสารกับธุรกิจล้มเหลว design ซับซ้อนเกินเหตุ หรือทีมขาดความรู้ใน domain) ประกอบด้วยกิจกรรมที่หมุนวนกัน:

Scenario Exploring — domain expert เล่า scenario ที่ทีมกังวล ด้วยตัวอย่างรูปธรรม แล้วทีม map ออกมาแบบ EventStorming
Modeling — ตรวจว่า model ปัจจุบันแก้ scenario นั้นได้ดีแค่ไหน
Challenging the Model — ท้าทาย model ด้วย scenario เพิ่มเพื่อพิสูจน์ว่าใช้ได้จริง
Harvesting & Documenting — เก็บ scenario สำคัญๆ ไว้เป็น reference scenario (แต่ไม่ต้องเก็บทุกการตัดสินใจ บางไอเดียควรทิ้งไว้ที่กระดาน)
Code Probing — เมื่อเกิด design breakthrough ให้พิสูจน์ใน code ว่า implement ได้จริง

ลอง ลอง แล้วลองอีก

คุณจะไม่ได้ model ที่ใช้ได้ตั้งแต่ความพยายามครั้งแรก และอาจไม่ได้แม้ในครั้งที่สองหรือสาม อย่ากลัวที่จะทดลอง จงฝึกฉีก design ทิ้งแล้วเริ่มใหม่ และจำไว้ว่าไม่มี “model ที่ถูกต้อง” มีแต่ “model ที่มีประโยชน์” ต่อ context และชุดปัญหาที่เผชิญอยู่ ณ ขณะนี้เท่านั้น

สรุปประเด็นสำคัญ

Knowledge Crunching คือศิลปะการกลั่นข้อมูลใน domain เพื่อคัดเฉพาะส่วนที่นำไปสร้าง model ที่มีประโยชน์ได้ และเป็นกระบวนการ ต่อเนื่อง ไม่ใช่ทำตอนเริ่ม project แล้วจบ
ความรู้ได้มาจากการ ร่วมมือ กับ domain expert รอบไวต์บอร์ด ผ่าน brainstorming และ prototyping แล้วตกผลึกออกมาเป็น Ubiquitous Language
stakeholder ให้ requirement (problem space) ส่วน domain expert ช่วยสร้าง model (solution space) — ทุ่มเวลาของ domain expert ไปกับส่วนที่เป็น core หรือซับซ้อนที่สุด
ตั้งคำถามทรงพลังเพื่อเข้าใจ เจตนา ของธุรกิจ และทำงาน “ร่วมกับ” ธุรกิจ ไม่ใช่ทำงาน “ให้” ธุรกิจ
ใช้ BDD/GWT, sketching, EventStorming, Impact Mapping, Business Model Canvas เพื่อทำให้การกลั่นความรู้สนุกและเห็นภาพ และใช้ Deliberate Discovery ขจัด unknown unknowns ตั้งแต่เนิ่นๆ

หัวใจของบทนี้

ก่อนจะออกแบบ solution ที่ดีได้ เราต้อง เข้าใจ problem domain อย่างลึกซึ้ง ผ่านการร่วมมือกับ domain expert เพราะ insight ที่แท้จริงเกิดจากการบดเคี้ยวความรู้ซ้ำแล้วซ้ำเล่า การทดลอง และความกล้าที่จะทิ้ง model ที่ไม่ดี — model ไม่มีคำว่าสมบูรณ์แบบ มีเพียง model ที่ตอบโจทย์ปัญหา ณ ขณะนี้เท่านั้น

🔗 อ้างอิงเพิ่มเติมใน DevIQ

เจาะลึกแนวคิดในบทนี้ต่อได้ที่คลังอ้างอิง DevIQ:

Ubiquitous Language — ภาษากลางที่เป็นผลผลิตหลักของ Knowledge Crunching ตามที่บทนี้อธิบาย
EventStorming — สรุปแนวคิดเวิร์กช็อปที่บทนี้ใช้เป็นเทคนิคหลักในการค้นพบ domain event และ command
Domain (Subdomain vs Core Domain) — ต่อยอดจากตอนท้ายบทที่ EventStorming ช่วยเผย subdomain และ core domain ออกมาให้เห็น

เช็กความเข้าใจ — บทที่ 2

ข้อ 1 / 4

Knowledge Crunching คืออะไรในความหมายของ DDD?

กลั่น problem domain ออก​มา

Knowledge Crunching คือ​อะไร

ภาษา​กลาง​คือ​ผลผลิต​ของ​การ​ร่วมมือ

domain expert ต่าง​จาก stakeholder อย่างไร

เทคนิค​กลั่น​ความ​รู้​ให้​ได้​ผล

โฟกัส​บทสนทนา​ที่​น่า​สนใจ​ที่สุด

เริ่ม​จาก use case แล้ว​ถาม​คำถาม​ทรง​พลัง