EventStorming

เวิร์กช็อปร่วมกันเพื่อเข้าใจ domain ที่ซับซ้อนผ่านเหตุการณ์

EventStorming เป็นเทคนิคเชิงเวิร์กช็อปที่ทรงพลังและเน้นการร่วมมือ ช่วยให้ทีมเข้าใจ domain ธุรกิจที่ซับซ้อนได้ลึกซึ้งขึ้น ผู้เข้าร่วมมาจากทั่วทั้งธุรกิจ — stakeholder, นักพัฒนา, ผู้เชี่ยวชาญ domain, business analyst, designer และใครก็ตามที่เกี่ยวข้อง

ความเจ็บปวดของการพัฒนาซอฟต์แวร์ส่วนหนึ่งมาจากปัญหาการสื่อสาร — ไซโล ภาษาที่ไม่ตรงกันระหว่างทีม EventStorming ช่วยข้ามอุปสรรคเหล่านี้ด้วยการนำทุกคนมาอยู่ในห้องเดียวกัน โดยมี facilitator (ดีที่สุดคือคนนอกที่ไม่ติดการเมืององค์กร) คอยจุดบทสนทนา ถามคำถามที่คนอื่นอาจไม่กล้าถาม และพากลุ่มสร้าง timeline ร่วม ของ domain หรือกระบวนการ โดยใช้ sticky note แทนเหตุการณ์ (event) และองค์ประกอบต่าง ๆ

นิยาม

Alberto Brandolini เป็นผู้คิดค้น EventStorming ขึ้นในปี 2013 โดยเริ่มจากการมองหาทางเลือกที่เร็วกว่าการเขียน UML diagram อย่างละเอียด ชื่อ “EventStorming” เกิดขึ้นระหว่างที่ Brandolini รับเชิญเป็นวิทยากรใน IDDD Tour ของ Vaughn Vernon — คำว่า “Event-based” ถูกใช้อยู่แล้วในเอกสารของ Vernon ทำให้ต้องรีแบรนด์ชื่อเทคนิคก่อนขึ้นพูดที่เมือง Leuven จนกลายมาเป็นคำเดียวคือ “EventStorming”

หัวใจของเทคนิคคือการให้กลุ่มคนเขียน domain event (สิ่งที่เกิดขึ้นแล้วใน domain ใช้กริยารูปอดีต เช่น “OrderPlaced”, “PaymentReceived”) ลงบน sticky note สีส้ม แล้วนำมาเรียงต่อกันบนกำแพงยาว ๆ (ไม่ต้องมีที่นั่ง เพื่อบังคับให้ทุกคนยืนและเคลื่อนไหวรอบ ๆ model) จนเกิดเป็น timeline ของกระบวนการทางธุรกิจทั้งหมด จากนั้นค่อย ๆ เพิ่มองค์ประกอบอื่นเข้าไปทีละชั้นด้วยสีที่มีความหมายต่างกัน — แนวทางที่ชุมชน ddd-crew สรุปไว้ในเอกสาร cheat sheet มีดังนี้:

Domain Event (สีส้ม) — สิ่งที่เกิดขึ้นแล้ว เขียนเป็นกริยารูปอดีต
Command (สีฟ้า) — การตัดสินใจหรือเจตนาที่ actor หรือระบบสั่งให้เกิดขึ้น อยู่ก่อนหน้า domain event ที่มันก่อให้เกิด
Actor (สีเหลืองเล็ก) — บุคคล ทีม หรือกลุ่มที่เกี่ยวข้องกับ event
Aggregate / Constraint (สีเหลืองใหญ่) — วัตถุหรือกฎทางธุรกิจที่ควบคุมว่า command ไหนจะได้รับอนุญาตให้เกิด event ได้
Policy (สีม่วงอ่อน) — กฎแบบ “เมื่อ X เกิดขึ้น ให้ทำ Y” ที่เชื่อม domain event หนึ่งไปสู่ command ถัดไป อาจเป็นระบบอัตโนมัติหรือคนทำเอง
Read Model / View (สีเขียว) — ข้อมูลที่ actor ต้องเห็นก่อนตัดสินใจสั่ง command
External System (สีชมพูกว้าง) — ระบบภายนอกที่ยิง command เข้ามาหรือรับ event ออกไป
Hotspot (สีชมพูนีออน วางเอียง) — จุดที่มีความขัดแย้ง ไม่แน่ใจ หรือคำถามที่ยังไม่มีคำตอบ ทำเครื่องหมายไว้เพื่อสำรวจภายหลังโดยไม่ทำให้ workshop สะดุด

Brandolini แบ่งระดับของ EventStorming ไว้หลายระดับ ตั้งแต่ Big Picture (มองภาพรวมทั้งองค์กรหรือ domain เพื่อหา pain point และขอบเขต), Process Modeling (ลงรายละเอียดกระบวนการทีละขั้น เห็น actor, policy, hotspot ชัดขึ้น), ไปจนถึง Software Design (ระดับที่ลึกพอจะนำไปแปลงเป็น aggregate, bounded context และ code จริงได้)

บทบาทใน DDD

EventStorming ไม่ใช่แค่เทคนิคระดมสมอง แต่เป็นสะพานเชื่อมระหว่างสองซีกของ DDD:

Strategic design — เมื่อทำ Big Picture EventStorming ทีมจะเห็น timeline ยาว ๆ ของทั้งองค์กร แล้วสังเกตได้ว่าจุดไหนภาษาที่ใช้เปลี่ยนไป จุดไหนมีความเป็นเจ้าของ (ownership) ต่างกัน — นี่คือสัญญาณของ Bounded Context ใหม่ ทำให้ EventStorming กลายเป็นเครื่องมือค้นหาขอบเขตของ context ที่รวดเร็วกว่าการนั่งวิเคราะห์เอกสารทีละหน้า
Ubiquitous Language — เพราะผู้เชี่ยวชาญ domain เป็นคนเลือกคำที่เขียนบน sticky note เอง ไม่ใช่นักพัฒนาแปลจากข้อกำหนด คำศัพท์ที่ได้จึงเป็นภาษากลางที่แม่นยำและทุกฝ่ายเข้าใจตรงกันตั้งแต่ต้น
Tactical design — เมื่อ workshop ลงลึกถึงระดับ Software Design, sticky note สีเหลือง (Aggregate) และลูกศรจาก Command ไปยัง Domain Event จะแปลงตรงเป็น code ได้เกือบทันที: Aggregate รับ Command ตรวจสอบ invariant แล้ว publish Domain Event ส่วน Policy ก็คือ event handler ที่ subscribe event หนึ่งแล้วยิง command ถัดไป — สอดคล้องโดยตรงกับรูปแบบ Domain Events ในเชิงสถาปัตยกรรม

เอกสารของ Microsoft ที่อธิบายการออกแบบ domain event ใน .NET ก็ยืนยันแนวคิดเดียวกัน: domain event คือสิ่งที่เกิดขึ้นแล้วใน domain ที่ส่วนอื่นของ domain เดียวกันควรรับรู้และตอบสนอง โดยชื่อ class ควรเป็นกริยารูปอดีตตามภาษาที่ผู้เชี่ยวชาญ domain ใช้ (ubiquitous language) เช่นเดียวกับที่ EventStorming กำหนดให้ sticky note สีส้มต้องเป็นกริยารูปอดีต — เป็นตัวอย่างที่ชัดเจนว่าผลลัพธ์จาก workshop ไหลตรงไปเป็นชื่อ class ใน code ได้เลย

ข้อดีอีกอย่างของ EventStorming ต่อ DDD คือมันเปิดโอกาสให้เห็น hotspot — จุดที่ทีมยังไม่เห็นตรงกัน หรือกฎธุรกิจที่ขัดแย้งกันเอง — ตั้งแต่ช่วงต้นของโครงการ ก่อนที่จะเขียน code ไปผิดทางแล้วค่อยมาแก้ทีหลังซึ่งมีต้นทุนสูงกว่ามาก

ตัวอย่าง

สมมติทีมทำ EventStorming เรื่องกระบวนการสั่งซื้อของร้านค้าออนไลน์ แล้วได้ timeline อย่างง่ายดังนี้ (Actor สั่ง Command, Aggregate ตรวจสอบแล้ว publish Domain Event, Policy รับ event แล้วสั่ง Command ต่อ, Read Model ให้ข้อมูลกลับไปยัง Actor):

graph LR
    Customer[Actor Customer] --> PlaceOrder[Command PlaceOrder]
    PlaceOrder --> OrderAggregate[Aggregate Order]
    OrderAggregate --> OrderPlaced[Domain Event OrderPlaced]
    OrderPlaced --> ReserveStockPolicy[Policy ReserveStock]
    ReserveStockPolicy --> ReserveStock[Command ReserveStock]
    ReserveStock --> InventorySystem[External System Inventory]
    OrderPlaced --> OrderSummary[Read Model OrderSummary]
    OrderSummary --> Customer

จาก sticky note เหล่านี้ ทีมสามารถแปลงตรงเป็น code C# ได้โดยที่ชื่อ class ยังคงคำศัพท์เดียวกับที่เขียนบนกำแพง:

// Command: มาจาก sticky note สีฟ้า "PlaceOrder"
public sealed record PlaceOrderCommand(Guid CustomerId, IReadOnlyList<OrderLine> Lines);

// Domain Event: มาจาก sticky note สีส้ม เขียนเป็นกริยารูปอดีต
public sealed record OrderPlaced(Guid OrderId, Guid CustomerId, DateTime OccurredOn);

// Aggregate: มาจาก sticky note สีเหลือง ควบคุม invariant ก่อนปล่อย event
public class Order
{
    private readonly List<object> _domainEvents = new();
    public Guid Id { get; private set; }
    public OrderStatus Status { get; private set; }

    public static Order Place(Guid customerId, IReadOnlyList<OrderLine> lines)
    {
        if (lines.Count == 0)
        {
            // Hotspot ที่พบระหว่าง workshop: "สั่งซื้อออเดอร์ว่างได้ไหม" ทีมตกลงว่าไม่ได้
            throw new InvalidOperationException("ออเดอร์ต้องมีอย่างน้อยหนึ่งรายการ");
        }

        var order = new Order { Id = Guid.NewGuid(), Status = OrderStatus.Placed };
        order._domainEvents.Add(new OrderPlaced(order.Id, customerId, DateTime.UtcNow));
        return order;
    }

    public IReadOnlyList<object> DomainEvents => _domainEvents;
}

// Policy: มาจาก sticky note สีม่วง "เมื่อ OrderPlaced เกิดขึ้น ให้ ReserveStock"
public class ReserveStockPolicy : IDomainEventHandler<OrderPlaced>
{
    private readonly IInventoryClient _inventory;

    public ReserveStockPolicy(IInventoryClient inventory) => _inventory = inventory;

    public Task Handle(OrderPlaced domainEvent, CancellationToken cancellationToken)
        // ยิง Command ถัดไปไปยัง External System สีชมพู "Inventory"
        => _inventory.ReserveStockAsync(domainEvent.OrderId, cancellationToken);
}

จะเห็นว่า sticky note แต่ละสีบนกำแพงมีคู่ตรงกับองค์ประกอบทาง code: สีฟ้า to command object, สีส้ม to domain event record, สีเหลือง to aggregate ที่คุม invariant, สีม่วง to policy/event handler และสีชมพู to infrastructure client ที่คุยกับระบบภายนอก — นี่คือเหตุผลที่ EventStorming ระดับ Software Design เชื่อมตรงไปสู่การออกแบบ aggregate และ bounded context ได้อย่างเป็นธรรมชาติ

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

EventStorming มักถูกเทียบหรือใช้คู่กับเทคนิคอื่นในกล่องเครื่องมือของ DDD:

Domain Storytelling เน้นเล่าเรื่องผ่าน actor และ work object เป็นภาพ pictographic ทีละประโยค เหมาะกับกลุ่มเล็กที่ต้องการความละเอียดของ “ใครทำอะไรกับอะไร” ส่วน EventStorming เน้นเห็นภาพรวมของ timeline เหตุการณ์จำนวนมากพร้อมกัน เหมาะกับการหาขอบเขตและ pain point ในกลุ่มใหญ่ ทั้งสองเทคนิคเสริมกันได้ — เริ่มด้วย EventStorming เพื่อหาภาพกว้าง แล้วใช้ Domain Storytelling เจาะกระบวนการที่ซับซ้อนเฉพาะจุด
Ubiquitous Language คือผลพลอยได้โดยตรงของ EventStorming เพราะคำที่เขียนบน sticky note ทุกใบต้องผ่านการต่อรองและยอมรับร่วมกันของผู้เข้าร่วมทุกฝ่ายแบบ real-time
Bounded Context มักถูกค้นพบจากรอยต่อของ timeline ใน Big Picture EventStorming เช่น จุดที่คำว่า “Order” มีความหมายต่างกันระหว่างทีม Sales กับทีม Fulfillment
รูปแบบ Domain Events (ในเชิงสถาปัตยกรรมซอฟต์แวร์) คือปลายทางที่ sticky note สีส้มแปลงร่างไปเป็น เมื่อ workshop ลงถึงระดับ Software Design
Alberto Brandolini เน้นย้ำว่า EventStorming เป็น “การเรียนรู้ร่วมกันอย่างจงใจ” (deliberate collective learning) ไม่ใช่แค่เทคนิควาดไดอะแกรม จุดแข็งของมันคือความเร็วในการเปิดเผยปัญหาที่ซ่อนอยู่ ซึ่งช่วยฟื้นความนิยมของแนวคิด DDD และการ model ร่วมกัน (collaborative modeling) ในวงกว้างช่วงหลังปี 2013

EventStorming

นิยาม

บทบาท​ใน DDD

ตัวอย่าง

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

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

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

บทบาทใน DDD

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

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

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