Domain Storytelling

ให้ผู้เชี่ยวชาญเล่าเรื่อง แล้ววาด workflow ออกมาเป็นภาพ

การสื่อสารสำคัญมากใน DDD โดยเฉพาะในการพัฒนา ubiquitous language Domain Storytelling เปิดโอกาสให้ ผู้เชี่ยวชาญ domain เล่าเรื่อง จับภาพ workflow และวาดเรื่องราวเหล่านั้นออกมา

Domain Storytelling ถูกคิดค้นและตกผลึกเป็นวิธีปฏิบัติที่มีชื่อโดย Stefan Hofer และ Henning Schwentner (ผู้เขียนหนังสือ Domain Storytelling: A Collaborative, Visual, and Agile Way to Build Domain-Driven Software, Addison-Wesley, 2022 ในซีรีส์ที่ Vaughn Vernon เป็นบรรณาธิการ) เทคนิคนี้ประกอบด้วยสองส่วนที่แยกกันแต่เสริมกัน คือ pictographic language (ภาษาเชิงภาพ) สำหรับบันทึกเรื่องราว และ workshop format (รูปแบบเวิร์กช็อป) สำหรับดำเนินการ session

นิยาม

Domain Story คือแผนภาพที่แสดงว่า ใคร (actor) ทำอะไร (activity) กับสิ่งใด (work object) เรียงตามลำดับเหตุการณ์ที่มีหมายเลขกำกับ วาดขึ้นสด ๆ ระหว่างที่ผู้เชี่ยวชาญ domain เล่าเรื่องจริงจากงานประจำวันของตน โดยมี Moderator เป็นผู้จับภาพ

องค์ประกอบหลักของภาษาเชิงภาพมีเพียงไม่กี่แบบ ทำให้เรียนรู้ได้เร็ว:

Actor — icon รูปคนหรือระบบที่ลงมือทำกิจกรรม
Work object — สิ่งของหรือข้อมูลที่ actor ทำงานด้วย เช่น ใบสั่งซื้อ อีเมล เอกสาร
Activity — ลูกศรพร้อมคำกริยา เชื่อมจาก actor ไปยัง work object หรือ actor อีกราย
Sequence number — ตัวเลขกำกับลำดับเหตุการณ์ ทำให้เรื่องราวอ่านเป็นขั้นตอนได้ ไม่ใช่ภาพนิ่งเดียว
Annotation — หมายเหตุประกอบ เพิ่มรายละเอียดหรือเงื่อนไขที่ไม่ใช่กระแสหลักของเรื่อง

เรื่องราวถูกวาดด้วย icon และลูกศรพร้อม label เหล่านี้ ระหว่างเล่าเรื่องผ่านบทสนทนาและเวิร์กช็อป เป้าหมายที่บรรลุได้แก่ ubiquitous language ค่อย ๆ ก่อตัวขึ้นจากคำที่ผู้เชี่ยวชาญใช้จริง bounded context อาจถูกระบุจากขอบเขตของเรื่องที่เล่า และข้อกำหนดกับ scope เริ่มชัดเจนขึ้นเพราะทุกคนเห็นภาพเดียวกัน

Domain Storytelling มีเครื่องมือ open-source ชื่อ Egon.io สำหรับวาดเรื่องราวแบบดิจิทัลบนเว็บ ทำให้ทีมที่กระจายกันทางภูมิศาสตร์ก็ทำ session ร่วมกันได้

บทบาทใน DDD

Domain Storytelling ทำงานในช่วงต้นของกระบวนการ DDD โดยเฉพาะใน strategic design และการค้นหา domain ก่อนที่จะลงลึกไปถึง tactical patterns:

สร้าง Ubiquitous Language — คำศัพท์ที่ผู้เชี่ยวชาญใช้เล่าเรื่อง (คำกริยาบน activity, ชื่อของ work object) กลายเป็นคำศัพท์ร่วมที่ทีมพัฒนานำไปใช้ตั้งชื่อ class method และตัวแปรใน code
ช่วยค้นหา Bounded Context — เมื่อเรื่องราวหลายเรื่องเกี่ยวพันกับกลุ่มของ actor และ work object ที่ต่างกัน มักบ่งชี้ว่ามี context แยกกันซ่อนอยู่ ซึ่งต่อยอดไปสู่การทำ Context Mapping
ตรวจสอบความเข้าใจแบบทันที — เพราะภาษาเชิงภาพเรียบง่าย ผู้เชี่ยวชาญ domain อ่านแผนภาพที่ moderator วาดได้ทันทีและแก้ไขความเข้าใจผิดได้สด ๆ ระหว่าง session ไม่ต้องรอจนถึงรอบรีวิวในภายหลัง
เป็นจุดตั้งต้นให้ Domain Model — เรื่องราว (work object และ activity) มักกลายเป็นวัตถุดิบสำหรับออกแบบ Entity Value Object และ Aggregate ในขั้น tactical design ต่อไป

บทบาทใน session เวิร์กช็อปได้แก่:

Moderator / Facilitator — ดำเนิน session ถามคำถามให้เรื่องราวไหลลื่น และวาดหรือควบคุมการวาด
Modeler — ผู้จับภาพเรื่องราวลงในภาษาเชิงภาพ (บางครั้งเป็นคนเดียวกับ Moderator)
Domain Experts — ผู้เล่าเรื่องจริงจากประสบการณ์ทำงาน เป็นแหล่งความรู้หลัก
Listeners — ผู้เข้าร่วมอื่น ๆ เช่นนักพัฒนา ที่ฟังและอาจถามคำถามเพื่อความชัดเจน

ตัวอย่าง

สมมติทีมกำลังสร้างระบบสั่งซื้อออนไลน์ และจัดเวิร์กช็อป Domain Storytelling กับพนักงานคลังสินค้า เรื่องราวที่ได้อาจมีลำดับดังนี้: (1) ลูกค้า ส่งใบสั่งซื้อ ให้ ระบบสั่งซื้อ, (2) ระบบสั่งซื้อ แจ้งเตือน พนักงานคลัง ด้วยรายการที่ต้องจัด, (3) พนักงานคลัง หยิบสินค้า จากชั้นวาง, (4) พนักงานคลัง บรรจุ สินค้าใส่กล่อง, (5) พนักงานคลัง ส่งมอบ พัสดุให้กับ บริษัทขนส่ง

graph LR
  Customer((ลูกค้า))
  OrderSystem[ระบบสั่งซื้อ]
  WarehouseStaff((พนักงานคลัง))
  PurchaseOrder[[ใบสั่งซื้อ]]
  Shelf[[ชั้นวางสินค้า]]
  Package[[พัสดุ]]
  Carrier((บริษัทขนส่ง))

  Customer -- 1 ส่ง --> PurchaseOrder
  PurchaseOrder -- รับโดย --> OrderSystem
  OrderSystem -- 2 แจ้งเตือน --> WarehouseStaff
  WarehouseStaff -- 3 หยิบสินค้าจาก --> Shelf
  WarehouseStaff -- 4 บรรจุใส่ --> Package
  WarehouseStaff -- 5 ส่งมอบให้ --> Carrier

code C# ต่อไปนี้แสดงตัวอย่างว่าคำศัพท์จากเรื่องราวข้างต้น (actor, activity, work object) แปลงเป็นแบบจำลอง domain เบื้องต้นได้อย่างไร โดยยึดถ้อยคำจากเรื่องที่เล่าให้มากที่สุด:

// work object จากเรื่องราว: ใบสั่งซื้อ (PurchaseOrder)
public class PurchaseOrder
{
    public string OrderId { get; }
    public string CustomerName { get; }
    private readonly List<OrderLine> _lines = new();

    public PurchaseOrder(string orderId, string customerName)
    {
        OrderId = orderId;
        CustomerName = customerName;
    }

    // activity จากเรื่องราว: "ลูกค้าส่งใบสั่งซื้อ"
    public void AddLine(string sku, int quantity)
    {
        _lines.Add(new OrderLine(sku, quantity));
    }
}

// actor จากเรื่องราว: พนักงานคลังสินค้า (WarehouseStaff)
public class WarehouseStaff
{
    // activity: "พนักงานคลังหยิบสินค้าจากชั้นวาง"
    public Package PickAndPack(PurchaseOrder order, Shelf shelf)
    {
        var package = new Package(order.OrderId);
        foreach (var line in order.Lines)
        {
            var item = shelf.Take(line.Sku, line.Quantity);
            package.Add(item);
        }
        return package;
    }

    // activity: "พนักงานคลังส่งมอบพัสดุให้บริษัทขนส่ง"
    public void HandOverToCarrier(Package package, Carrier carrier)
    {
        carrier.Accept(package);
    }
}

ข้อสังเกต: ชื่อ class และ method ข้างต้นดึงมาจากคำที่ผู้เชี่ยวชาญพูดตรง ๆ ระหว่างเล่าเรื่อง (ส่ง, แจ้งเตือน, หยิบ, บรรจุ, ส่งมอบ) นี่คือกลไกที่ Domain Storytelling ใช้สร้าง ubiquitous language ให้ไหลจากปากผู้เชี่ยวชาญ domain เข้าสู่ code โดยตรง

ความสัมพันธ์กับแนวคิดอื่น

Domain Storytelling ไม่ได้บังคับว่าต้องใช้คู่กับ DDD เสมอไป แต่ในทางปฏิบัติมักใช้ร่วมกัน เพราะทั้งสองเน้นภาษาที่ตรงกับความเข้าใจของผู้เชี่ยวชาญ domain (ubiquitous language) เป็นแกนกลาง

เมื่อเทียบกับ EventStorming ซึ่งเป็นเทคนิค collaborative modeling อีกแบบที่ริเริ่มโดย Alberto Brandolini ทั้งสองมีจุดร่วมคือใช้การเล่าเรื่องเป็นลำดับเหตุการณ์เพื่อทำความเข้าใจ domain ที่ซับซ้อน แต่ต่างกันที่ EventStorming เน้น domain event (สิ่งที่เกิดขึ้นแล้วในอดีต) และใช้ sticky note สีต่าง ๆ แทนภาษาเชิงภาพคงที่ ในขณะที่ Domain Storytelling เน้น actor-activity-work object พร้อมลำดับเลขกำกับที่ตายตัวกว่า ทีมบางทีมเลือกผสมทั้งสองเทคนิคเข้าด้วยกัน เช่น ใช้ EventStorming มองภาพกว้างทั้งองค์กรก่อน แล้วใช้ Domain Storytelling ลงรายละเอียดเฉพาะส่วนที่ซับซ้อน

graph TD
  DomainStorytelling[Domain Storytelling]
  PictographicLanguage[Pictographic Language]
  WorkshopFormat[Workshop Format]
  UL[Ubiquitous Language]
  BC[Bounded Context]
  EventStorming[EventStorming]
  StrategicDesign[Strategic Design]

  DomainStorytelling --> PictographicLanguage
  DomainStorytelling --> WorkshopFormat
  DomainStorytelling --> UL
  DomainStorytelling --> BC
  DomainStorytelling --> StrategicDesign
  EventStorming --> StrategicDesign
  DomainStorytelling -.complementary.-> EventStorming

Domain Storytelling

นิยาม

บทบาทใน DDD

ตัวอย่าง

ความสัมพันธ์กับแนวคิดอื่น

ที่เกี่ยวข้อง

แหล่งอ้างอิง

Domain Storytelling

นิยาม

บทบาท​ใน DDD

ตัวอย่าง

ความ​สัมพันธ์​กับ​แนวคิด​อื่น

ที่​เกี่ยวข้อง

แหล่ง​อ้างอิง

บทบาทใน DDD

ความสัมพันธ์กับแนวคิดอื่น

ที่เกี่ยวข้อง

แหล่งอ้างอิง