Chương 12: Phương Pháp EventStorming

Giới Thiệu: Nghệ Thuật Khám Phá Miền Nghiệp Vụ

Như chúng ta đã nhấn mạnh xuyên suốt từ Chương 1 đến nay: Tri thức miền nghiệp vụ (Domain Knowledge) là yếu tố quyết định thành bại số một của mọi dự án phần mềm.

Thế nhưng, việc khai phá tri thức miền trong thực tế thường là một quá trình vô cùng chậm chạp, dễ nản lòng và ngập tràn hiểu lầm:

• Tài liệu đặc tả yêu cầu kinh doanh (SRS / BRD) dài hàng trăm trang thường lỗi thời ngay khi vừa in ra và chứa đầy những thuật ngữ mơ hồ.
• Các phòng ban làm việc trong những chiếc "silo" cô lập: kỹ sư không hiểu ngôn ngữ kinh doanh, chuyên gia nghiệp vụ không hiểu các ràng buộc công nghệ, và các nhà quản lý chỉ nhìn thấy bức tranh bề nổi.

Để phá vỡ sự bế tắc này, nhà tư vấn kiến trúc người Ý Alberto Brandolini đã phát minh ra EventStorming — một phương pháp hội thảo hợp tác trực quan với nhịp độ nhanh (fast-paced visual workshop), quy tụ tất cả các bên liên quan vào cùng một căn phòng để mô hình hóa toàn bộ dòng chảy nghiệp vụ phức tạp chỉ trong vòng vài giờ đồng hồ!

EventStorming Là Gì?

EventStorming là một định dạng workshop linh hoạt, tập trung vào việc mô hình hóa các quy trình kinh doanh thông qua chuỗi các sự kiện diễn ra theo trục thời gian.

Khác với các buổi họp phân tích truyền thống (nơi một người nói và mười người nghe gật gù), EventStorming là một hoạt động tương tác trực tiếp toàn diện: mọi thành viên tham gia đều cầm bút, viết ý tưởng lên những tờ giấy ghi chú dán (sticky notes) nhiều màu sắc và cùng nhau dán lên một bức tường dài vô tận.

Chuẩn Bị Gì Cho Buổi Hội Thảo EventStorming?

Để một buổi EventStorming diễn ra bùng nổ và hiệu quả cao nhất, khâu chuẩn bị hậu cần là cực kỳ thiết yếu:

1. Không Gian Mô Hình Hóa Rộng Lớn (Modeling Space)

Hãy quên đi những chiếc bảng trắng kích thước tiêu chuẩn trong phòng họp! Chúng quá nhỏ và sẽ nhanh chóng bị lấp đầy chỉ sau 15 phút đầu tiên, bóp nghẹt tư duy của những người tham gia.

Giải pháp tốt nhất: Mua một cuộn giấy vẽ kiến trúc lớn (Plotter paper / Butcher paper) dài ít nhất 8 đến 10 mét, dán căng ngang dọc theo bức tường của phòng hội thảo (Hình 12-1). Cảm giác có một "không gian vô hạn" sẽ kích thích mọi người tự do đóng góp ý tưởng mà không sợ hết chỗ.

2. Giấy Ghi Chú Đa Màu Sắc & Bút Lông Chuyên Dụng

Mỗi khái niệm trong EventStorming được quy ước bằng một màu giấy ghi chú riêng biệt. Bạn cần chuẩn bị số lượng dồi dào các tệp giấy:

• Màu cam (Orange): Dành cho Domain Events (cần nhiều nhất!).
• Màu xanh lam (Blue): Dành cho Commands.
• Màu vàng nhỏ (Small Yellow): Dành cho Actors / Users.
• Màu tím / hoa cà (Lilac): Dành cho Policies / Business Rules.
• Màu xanh lá cây (Green): Dành cho Read Models / Views.
• Màu hồng nhạt (Pink / Slate): Dành cho External Systems.
• Màu hồng đậm (Hot Pink / Red): Dành cho Hot Spots / Pain Points.
• Màu vàng lớn (Pale Yellow): Dành cho Aggregates.

3. Mời Đúng Các Bên Liên Quan (The Right People)

Một buổi EventStorming sẽ thất bại nếu chỉ có các kỹ sư phần mềm ngồi tự suy diễn nghiệp vụ với nhau. Bạn bắt buộc phải mời đầy đủ:

• Chuyên gia miền (Domain Experts): Nhân viên kinh doanh, quản lý sản phẩm, nhân viên chăm sóc khách hàng, kế toán — những người nắm giữ sự thật về cách thức doanh nghiệp vận hành.
• Kỹ sư phần mềm & Kiến trúc sư: Những người sẽ hiện thực hóa hệ thống.
• Kỹ sư kiểm thử (QA): Những người có tư duy phản biện sắc bén, luôn đặt câu hỏi về các trường hợp ngoại lệ (Edge Cases).

4. Quy Tắc Vàng: Loại Bỏ Toàn Bộ Ghế Ngồi!

Alberto Brandolini có một quy tắc nổi tiếng: Dọn sạch toàn bộ ghế ngồi ra khỏi phòng hội thảo!

Khi ngồi vào ghế, người ta có xu hướng thụ động, kiểm tra điện thoại hoặc rơi vào trạng thái buồn ngủ. Khi tất cả cùng đứng dậy, năng lượng trong phòng sẽ tăng vọt, các cuộc thảo luận diễn ra sôi nổi hơn, và mọi người dễ dàng di chuyển lại gần bức tường để chỉ trỏ, bổ sung và tranh luận trực tiếp.

Quy Trình 10 Bước Thực Hiện EventStorming

Một phiên EventStorming hoàn chỉnh dẫn dắt cả đội ngũ đi từ một bức tranh hỗn độn ban đầu đến một thiết kế kiến trúc chiến thuật sắc sảo qua 10 bước bài bản:

Bước 1: Khám Phá Tự Do (Unstructured Exploration)

Phát cho mỗi người một tệp giấy màu cam và bút lông. Trong vòng 15-20 phút, mọi người độc lập viết ra tất cả các Domain Events mà họ nghĩ là xảy ra trong quy trình nghiệp vụ và dán tự do lên tường mà không cần quan tâm đến thứ tự (Hình 12-2).

Bước 2: Xây Dựng Dòng Thời Gian (Timelines / Flows of Events)

Cả đội ngũ cùng nhau bước lên tường, di chuyển các mảnh giấy cam để sắp xếp chúng theo trình tự thời gian từ trái sang phải (Hình 12-3).

Trong quá trình này, đội ngũ sẽ loại bỏ các sự kiện bị trùng lặp, bổ sung những sự kiện còn thiếu ở giữa, và phát hiện ra các nhánh xử lý song song hoặc luồng rẽ nhánh điều kiện.

Bước 3: Đánh Dấu Điểm Nóng Tranh Luận (Pain Points / Hot Spots)

Bất cứ khi nào xuất hiện sự bất đồng ý kiến, một câu hỏi chưa có lời đáp ("Chỗ này do ai phê duyệt?", "Nếu khách hủy phòng lúc 23:00 thì tính thế nào?"), hoặc một quy trình thủ công gây bức xúc, người điều phối sẽ dán một tờ giấy màu hồng đậm xoay chéo 45 độ (Hình thoi - Hot Spot) ngay tại vị trí sự kiện đó (Hình 12-4).

Việc dán giấy Hot Spot giúp giữ cho nhịp độ buổi hội thảo không bị tắc nghẽn: ghi nhận vấn đề để giải quyết sau, cho phép dòng chảy sự kiện tiếp tục tiến lên mà không bị sa lầy vào những cuộc cãi vã kéo dài hàng giờ!

Bước 4: Xác Định Sự Kiện Then Chốt (Pivotal Events)

Người tham gia tìm kiếm các Sự kiện Then chốt (Pivotal Events) — những sự kiện cột mốc báo hiệu sự chuyển giao trạng thái quan trọng hoặc sự thay đổi ngữ cảnh trong quy trình nghiệp vụ (Hình 12-5).

Ví dụ: Đơn hàng đã đặt (Order Placed), Thanh toán đã xác nhận (Payment Confirmed), Hàng đã giao (Order Shipped). Những sự kiện then chốt này thường là những ứng cử viên sáng giá đầu tiên cho các ranh giới Bounded Context sau này.

Bước 5: Lệnh & Tác Nhân (Commands & Actors)

Hỏi câu hỏi: "Điều gì đã kích hoạt sự kiện này xảy ra?".

Thêm vào các tờ giấy màu xanh lam (Command - viết ở thì mệnh lệnh: `Đặt đơn hàng`, `Hủy vé`) và các tờ giấy nhỏ màu vàng (Actor - người thực hiện: `Khách hàng`, `Nhân viên hỗ trợ`) dán ngay trước sự kiện màu cam (Hình 12-6).

Bước 6: Chính Sách Tự Động Hóa (Policies / Automation Rules)

Không phải lệnh nào cũng do con người bấm nút. Rất nhiều thao tác được hệ thống thực thi tự động theo quy tắc nghiệp vụ:

MỖI KHI [Sự kiện X xảy ra] → THÌ [Thực thi Lệnh Y]

Các quy tắc này được viết lên giấy màu tím hoa cà (Lilac - Policy) và đặt nằm giữa sự kiện kích hoạt và lệnh được phát ra (Hình 12-7). Ví dụ: "Mỗi khi Thanh toán đã nhận → Thì tự động chạy lệnh Giao hàng".

Bước 7: Mô Hình Đọc & Giao Diện (Read Models / Views)

Để một Actor (con người) có thể đưa ra quyết định thực thi Command, họ cần được nhìn thấy những thông tin gì trên màn hình?

Thêm vào các tờ giấy màu xanh lá cây (Green - Read Model) mô tả ngắn gọn góc nhìn dữ liệu mà người dùng cần (Hình 12-8). Ví dụ: Màn hình giỏ hàng, Bảng giá vé máy bay.

Bước 8: Hệ Thống Ngoại Vi (External Systems)

Dán các tờ giấy màu hồng nhạt / đá phiến (Pink / Slate) đại diện cho các hệ thống bên thứ ba hoặc các dịch vụ bên ngoài tham gia vào luồng công việc: cổng thanh toán Stripe/PayPal, hệ thống CRM Salesforce, dịch vụ giao vận (Hình 12-9).

Bước 9: Gom Nhóm Thành Các Aggregates

Khi các chuỗi Command → Event đã rõ ràng, các kỹ sư cùng chuyên gia miền bắt đầu gom các Command và Event liên quan chặt chẽ về mặt tính nhất quán vào các tờ giấy lớn màu vàng nhạt (Pale Yellow - Aggregate) (Hình 12-10).

Bước 10: Định Hình Các Ranh Giới Bounded Contexts

Bước cuối cùng mang tính chiến lược: Dùng bút dạ vẽ các đường bao quanh các nhóm Aggregate và Policy có cùng Ngôn ngữ Toàn hiện diện và mục tiêu nghiệp vụ. Đây chính là các ứng cử viên hoàn hảo cho các Bounded Contexts của hệ thống (Hình 12-11)!

Bảng Bảng Màu Chuẩn Của EventStorming (Cheat Sheet)

Hình 12-12 là bảng quy ước màu sắc chuẩn quốc tế do Alberto Brandolini thiết lập. Hãy in ra hoặc dán ở góc bức tường workshop để mọi người luôn ghi nhớ:

Kinh Nghiệm Điều Phối Buổi Hội Thảo (Facilitation Tips)

Một buổi EventStorming có thành công hay không phụ thuộc rất lớn vào kỹ năng của người điều phối (Facilitator):

• Giữ cho năng lượng luôn ở mức cao: Nếu thấy không khí lắng xuống, hãy khuyến khích mọi người: "Chuyện gì xảy ra tiếp theo sau sự kiện này?" hoặc "Nếu có lỗi xảy ra ở bước này thì sao?".
• Khuyến khích những người rụt rè: Trong mọi tập thể, luôn có những người ít nói nhưng lại nắm giữ tri thức nghiệp vụ sâu sắc. Người điều phối cần chủ động bước lại gần, hỏi ý kiến của họ và khuyến khích họ viết lên giấy dán lên tường.
• Ngăn chặn "Kẻ thống trị": Đôi khi một người quản lý cấp cao hoặc một kỹ sư thích nói nhiều sẽ có xu hướng áp đặt quan điểm của mình lên cả phòng. Hãy nhắc nhở lịch sự: "Mọi người đều viết giấy của mình trước, sau đó chúng ta sẽ cùng tranh luận trên tường".
• Không sa đà vào chi tiết kỹ thuật quá sớm: Nếu các lập trình viên bắt đầu cãi nhau về việc chọn MySQL hay MongoDB, hãy dán ngay một giấy Hot Spot lên tường và yêu cầu quay trở lại với dòng chảy nghiệp vụ.

Khi Nào Nên Tổ Chức EventStorming?

EventStorming là một công cụ đa năng có thể áp dụng trong rất nhiều giai đoạn của vòng đời phần mềm:

Tổng Kết Chương

EventStorming là một trong những đóng góp thực tiễn vĩ đại nhất cho phong trào Domain-Driven Design hiện đại:

• Nó biến việc mô hình hóa phần mềm từ một bài tập lý thuyết trừu tượng thành một hoạt động xã hội đầy năng lượng và gắn kết.
• Nó đưa Domain Events trở thành đồng tiền chung trong giao tiếp giữa giới kinh doanh và giới kỹ thuật.
• Nó tạo ra đầu ra cụ thể: Ngôn ngữ Toàn hiện diện, danh sách các Hot Spots cần giải quyết, cấu trúc các Aggregate, và ranh giới tự nhiên của các Bounded Contexts.

Nhưng khi bước ra khỏi phòng hội thảo EventStorming và đối mặt với thực tế doanh nghiệp — nơi có các hệ thống Monolith khổng lồ, áp lực tiến độ từ ban lãnh đạo, và sự kháng cự thay đổi từ các đội ngũ — làm thế nào để áp dụng Domain-Driven Design thành công trong thế giới thực?

Hãy cùng khám phá các chiến lược sinh tồn trong Chương 13: Domain-Driven Design Trong Thực Tế (DDD in the Real World)!

Bài Tập Ôn Tập & Thảo Luận Thực Tiễn

Dưới đây là 3 câu hỏi ôn tập kèm lời giải chi tiết và trích dẫn chuẩn xác từ tác giả Vlad Khononov (Appendix B).