Khám phá và thiết kế miền nghiệp vụ dựa trên EventStorming
1. Tổng quan
Định nghĩa: EventStorming là workshop mô hình hóa mang tính cộng tác, trong đó các bên liên quan và nhà phát triển cùng ở một không gian, trải các sự kiện miền (domain event) theo trình tự thời gian và cùng nhau khám phá sự thật, quy tắc, trách nhiệm và ranh giới của một lĩnh vực nghiệp vụ phức tạp.
Thất bại của dự án phần mềm không chỉ xảy ra do chọn sai công nghệ (technology stack). Khi thuật ngữ mà người phụ trách nghiệp vụ sử dụng khác với ý nghĩa của đối tượng do nhà phát triển thiết kế, hoặc khi mỗi phòng ban hiểu cùng một nghiệp vụ theo trình tự và trách nhiệm khác nhau, thì yêu cầu đã lung lay ngay trước khi được cố định thành tài liệu. Đặc biệt, những nghiệp vụ đan xen nhiều phòng ban và hệ thống bên ngoài như đặt hàng, thanh toán, giao hàng, hoàn tiền rất khó giải thích toàn bộ luồng chỉ bằng danh sách màn hình hay bảng CRUD đơn thuần.
EventStorming là phương pháp làm lộ ra sự đứt gãy tri thức đó trước tiên bằng đối thoại và mô hình trực quan.
Người tham gia không bắt đầu bằng việc xác định hệ thống lưu trữ gì, mà viết các sự thật đã xảy ra trong nghiệp vụ dưới dạng câu ở thì quá khứ.
Ví dụ, khi xếp các sự kiện như Đơn hàng đã được tiếp nhận, Thanh toán đã được phê duyệt, Sản phẩm đã được xuất kho lên trục thời gian, điểm chung và xung đột trong luồng nghiệp vụ mà những người khác nhau hình dung sẽ cùng lúc hiện ra.
Cốt lõi của cách làm này không phải là một người đưa ra bản thiết kế đúng, mà là chuyên gia miền và người làm kỹ thuật cùng xây dựng mô hình, qua đó thực hiện học tập tập thể (collective learning). Do đó, kết quả không chỉ là biên bản họp mà trở thành điểm xuất phát cho các ứng viên ngôn ngữ chung (ubiquitous language), quy tắc nghiệp vụ, câu hỏi chưa giải quyết, ứng viên ranh giới và thiết kế tiếp theo. EventStorming hỗ trợ thiết kế hướng miền (DDD) nhưng không thay thế mọi hoạt động của DDD, và cũng không phải kỹ thuật loại bỏ UML, BPMN hay mô hình dữ liệu.
1.1 Bối cảnh ra đời và sự cần thiết
Phân tích truyền thống đi theo luồng tuyến tính: phỏng vấn lấy yêu cầu, nhà phân tích tổng hợp nội dung rồi chuyển cho nhà phát triển dưới dạng tài liệu. Trong quá trình này, tri thức ngầm (tacit knowledge) của người trực tiếp làm nghiệp vụ bị lược bỏ khi tài liệu hóa, và mỗi khi có câu hỏi lại phải xếp lịch họp. Nếu lỗi không được phát hiện cho đến khi tài liệu hoàn tất, chi phí làm lại ở giai đoạn triển khai sẽ tăng vọt.
Ngược lại, trong EventStorming mọi người cùng lúc dán và di chuyển thẻ trên một bức tường lớn hoặc bảng số. Trực quan hóa nhanh làm lộ ngay những bất nhất vốn chỉ tồn tại trong lời nói, và vì chi phí thay đổi vị trí và câu chữ trên thẻ thấp nên có thể phá bỏ giả thuyết ban đầu một cách an toàn. Nhà phát triển trực tiếp nghe quy tắc nghiệp vụ, còn người làm nghiệp vụ được hỏi về ràng buộc kỹ thuật và luồng dữ liệu, nhờ đó hai bên hiệu chỉnh góc nhìn của nhau.
Kỹ thuật này đặc biệt hiệu quả trong các điều kiện sau. Thứ nhất, khi thuật ngữ nghiệp vụ khác nhau giữa các phòng ban và ranh giới trách nhiệm giữa các hệ thống không rõ ràng. Thứ hai, khi hiện đại hóa hệ thống kế thừa (legacy) và cần hiểu đồng thời hành vi hiện tại lẫn nghiệp vụ mục tiêu. Thứ ba, khi cần khám phá vùng vấn đề của dịch vụ mới trong thời gian ngắn và xác định phạm vi MVP. Thứ tư, khi các ngoại lệ không thể giải thích chỉ bằng luồng bình thường là quan trọng, như sự cố, khiếu nại hay ứng phó quy định.
1.2 Mục tiêu và phi mục tiêu
Mục tiêu của EventStorming là giúp mọi người hiểu cùng một sự kiện bằng cùng một tên gọi đối với miền nghiệp vụ phức tạp. Khi workshop kết thúc, không cần mọi thiết kế chi tiết đều được quyết định, nhưng phải làm rõ điều gì đã xảy ra, ai là nguyên nhân, chính sách nào tự động phản ứng, và sự bất định nằm ở đâu. Qua kết quả này, nhóm có thể xác định ưu tiên điều tra và các quyết định thiết kế.
Ngược lại, EventStorming không phải hoạt động tạo ra lược đồ cơ sở dữ liệu đã chốt, đặc tả API hoàn chỉnh, mã kiểm thử chạy được hay sơ đồ tổ chức cuối cùng. Vị trí của thẻ là giả thuyết hiện tại của mô hình, quy tắc và ranh giới có thể thay đổi qua kiểm chứng sau đó. Vì vậy, nếu sao chép nguyên kết quả thành đặc tả triển khai sẽ gây tác dụng phụ là che giấu sự bất định của giai đoạn khám phá.
2. Nguyên lý cốt lõi và cấu trúc tổng thể
2.1 Tư duy lấy sự kiện làm trung tâm
Sự kiện miền là sự thật có ý nghĩa về mặt nghiệp vụ và đã xảy ra.
Sự kiện thường được diễn đạt bằng động từ thì quá khứ và danh từ, thể hiện kết quả chứ không phải ý định hay mệnh lệnh của ai đó.
Khách hàng đã bấm nút đặt hàng gần với hành vi hoặc lệnh, còn Đơn hàng đã được tiếp nhận là sự thật quan sát được trong miền.
Khi đặt sự kiện trước, người tham gia tập trung vào sự thay đổi của nghiệp vụ hơn là bảng cơ sở dữ liệu hay tên dịch vụ. Trong quá trình tranh luận về trình tự sự kiện, các điều kiện tiên quyết, phản ứng tiếp theo, độ trễ, hủy bỏ, thử lại và luồng bù trừ (compensation) xuất hiện một cách tự nhiên. Ngoài ra, có thể kiểm tra xem cùng một sự kiện có được dùng ở nhiều nơi không, giúp khám phá sự phụ thuộc giữa các dịch vụ và ứng viên ranh giới.
Tên sự kiện phải ưu tiên thuật ngữ nghiệp vụ hơn công nghệ triển khai.
Ví dụ, OrderStatus = 3 là giá trị trạng thái trong cơ sở dữ liệu, còn Thanh toán đã được phê duyệt là sự thật mà người làm nghiệp vụ cũng hiểu được.
Ban đầu không ép buộc tên hoàn hảo; các cách diễn đạt gây tranh cãi được đánh dấu là hotspot riêng rồi tinh chỉnh thành ngôn ngữ chung sau workshop.
flowchart LR
A[Chuyên gia miền, nhà phát triển, người vận hành] --> B[Thu thập sự thật xảy ra trong nghiệp vụ]
B --> C[Dòng thời gian sự kiện miền ở thì quá khứ]
C --> D[Bổ sung lệnh, tác nhân, chính sách, mô hình đọc]
D --> E[Hotspot, ngoại lệ, câu hỏi chưa giải quyết]
E --> F[Ứng viên ranh giới, trách nhiệm, ngôn ngữ chung]
F --> G[Thiết kế DDD, API, sự kiện, kiểm thử]
G -. Phản ánh kết quả kiểm chứng .-> C
Cấu trúc trên cho thấy phân tích không kết thúc bằng một lần tạo sản phẩm đầu ra. Các câu hỏi lộ ra trên dòng thời gian được kiểm chứng bằng phỏng vấn bổ sung hoặc phân tích log, và kết quả kiểm chứng lại làm thay đổi tên và trình tự sự kiện. Các ngoại lệ phát hiện ở giai đoạn thiết kế cũng phải được đưa trở lại mô hình miền, nên EventStorming gần với một vòng lặp học tập lặp đi lặp lại.
2.2 Màu sắc và các thành phần mô hình
Màu sắc không phải cú pháp bắt buộc như tiêu chuẩn quốc tế, mà là quy ước trực quan giúp đối thoại giữa những người tham gia. Nhóm có thể dùng hệ màu khác, nhưng phải thống nhất bảng màu và ví dụ khi bắt đầu, và không đổi ý nghĩa giữa chừng. Bảng sau tổng hợp bảng màu cơ bản được dùng rộng rãi và các câu hỏi đi kèm.
| Thành phần | Màu tiêu biểu | Dạng câu | Câu hỏi cần kiểm tra |
|---|---|---|---|
| Sự kiện miền | Cam | đã được ~ |
Sự thật nào đã xảy ra? |
| Lệnh (command) | Xanh dương | Hãy ~ |
Điều gì đã gây ra sự kiện? |
| Tác nhân (actor) | Vàng | Người dùng, hệ thống, vai trò | Ai đã đưa ra lệnh? |
| Chính sách (policy) | Tím | Nếu ~ thì ~ |
Quy tắc nào vận hành sau sự kiện? |
| Mô hình đọc (read model) | Xanh lá | Màn hình tra cứu, dữ liệu phán đoán | Cần đọc gì trước khi ra lệnh? |
| Aggregate | Hồng nhạt | Đơn vị trách nhiệm nghiệp vụ | Tính nhất quán nào phải được giữ cùng nhau? |
| Hotspot | Đỏ hoặc hồng | Câu hỏi, xung đột, rủi ro | Điều gì vẫn chưa biết? |
| Ranh giới | Đường kẻ hoặc nhãn hồng | Ứng viên bounded context | Thuật ngữ và quy tắc thay đổi ở đâu? |
Quan trọng hơn màu sắc trong bảng là quan hệ nhân quả giữa các thành phần. Lệnh là ý định của một tác nhân nào đó, và khi lệnh thành công thì một hoặc nhiều sự kiện xảy ra. Sự kiện có thể kích hoạt chính sách hoặc cập nhật mô hình đọc, và có thể được chuyển thành thông điệp tới context khác. Do đó, không chỉ liệt kê thẻ mà phải dùng mũi tên và đối thoại để giải thích “vì sao sự kiện này xảy ra”.
Tác nhân không chỉ là con người. Khách hàng, nhân viên tư vấn, tác vụ batch, cổng thanh toán, cơ quan quản lý bên ngoài, hay bounded context khác đều có thể là chủ thể của lệnh hoặc bên tiêu thụ sự kiện. Biểu diễn hệ thống bên ngoài như con người là thủ pháp mô hình hóa để tìm trách nhiệm và điểm tích hợp, không có nghĩa là chúng thực sự có cùng mức độ tin cậy.
Chính sách thể hiện phản ứng tự động kiểu “khi sự kiện xảy ra thì luôn làm gì đó”.
Ví dụ, chính sách Khi thanh toán được phê duyệt thì yêu cầu chuẩn bị giao hàng giải thích sự gắn kết giữa thanh toán và giao hàng.
Tuy nhiên, chính sách là lời gọi đồng bộ hay tiêu thụ sự kiện bất đồng bộ, có thử lại và bù trừ khi thất bại hay không, phải để lại như câu hỏi thiết kế riêng.
2.3 Vai trò của hotspot
Hotspot không phải là lỗ hổng của mô hình mà là sản phẩm hạng nhất phục vụ việc học.
Nếu người tham gia dùng Hoàn tiền hoàn tất và Hoàn tiền được phê duyệt với nghĩa khác nhau, hoặc chưa xác định ai chịu trách nhiệm hoàn tiền một phần, thì đánh dấu bằng thẻ đỏ.
So với việc cố kết thúc tranh luận và chọn thuật ngữ tùy ý, làm hiện rõ sự bất định sẽ nâng cao chất lượng của các quyết định tiếp theo.
Hotspot có thể có mức ưu tiên. Các câu hỏi có rủi ro pháp lý lớn, ảnh hưởng trực tiếp đến quyết toán tiền, hoặc liên quan đến sự cố lặp lại được điều tra trước; khác biệt thuần túy về cách diễn đạt được xếp sau. Khi gắn người phụ trách và thời hạn xác nhận cho từng hotspot, workshop không dừng lại ở bảng ý tưởng mà trở thành backlog khám phá có thể thực thi.
3. Quy trình tiến hành workshop
3.1 Giai đoạn chuẩn bị
Người điều phối (facilitator) trước tiên xác định phạm vi khám phá và điều kiện bắt đầu, kết thúc của trục thời gian.
Cần mô tả một mục đích nghiệp vụ cùng điểm đầu và cuối, như từ sau thanh toán đến giao hàng của đơn hàng trực tuyến; phạm vi kiểu “mô hình hóa toàn bộ công ty” là quá rộng.
Người tham gia cần có gồm chuyên gia miền, người chịu trách nhiệm sản phẩm, nhà phát triển, kiến trúc sư, người phụ trách vận hành và hỗ trợ khách hàng, và nếu có thể thì mời cả chủ thể của các tích hợp bên ngoài.
Trong workshop trực tiếp, cần bố trí đủ diện tích tường, chuẩn bị nhiều giấy ghi chú và bút dạ nét đậm cho mỗi người tham gia. Trong workshop trực tuyến, cần kiểm tra trước quyền truy cập canvas vô hạn, mẫu màu, chất lượng âm thanh hội nghị truyền hình, múi giờ và cách thu thập ý kiến ẩn danh. Dù công cụ có hào nhoáng, nếu khó di chuyển thẻ và chỉnh sửa đồng thời thì thảo luận sẽ chậm lại, vì vậy ưu tiên luồng làm việc hơn tính năng.
Trước khi bắt đầu, hướng dẫn các nguyên tắc vận hành sau. Thứ nhất, ưu tiên sự thật của miền hơn cấp bậc, và ai cũng được dán thẻ. Thứ hai, mỗi thẻ chỉ viết một ý nghĩa. Thứ ba, không che giấu nội dung chưa chắc chắn mà đánh dấu thành hotspot. Thứ tư, kể cả khi thuật ngữ triển khai xuất hiện, hãy dịch lại thành sự kiện nghiệp vụ. Thứ năm, không cố giải quyết ngay mọi bất đồng mà tuân thủ khung thời gian (timebox).
3.2 Big Picture EventStorming
Giai đoạn Big Picture là giai đoạn trải nhanh toàn bộ luồng. Người tham gia trước tiên viết các sự kiện miền mình biết lên thẻ màu cam ở thì quá khứ và dán lên tường mà không cố sắp xếp đúng hoàn toàn theo thời gian. Ban đầu thẻ bị trùng lặp và mâu thuẫn cũng không sao, bởi chính sự trùng lặp và mâu thuẫn cho thấy khoảng cách tri thức.
Tiếp theo, người tham gia đọc thẻ, gom các luồng tương tự và đặt câu hỏi về khoảng trống, xung đột giữa các sự kiện. Trong quá trình này, không chỉ luồng bình thường của nghiệp vụ mà cả các sự kiện hủy, thất bại, xử lý lại, hết hạn, tạm hoãn và bù trừ cũng được ghi lại. Ví dụ, nếu chỉ ghi phê duyệt thanh toán thì sẽ bỏ sót các vấn đề vận hành thực tế như phê duyệt thất bại, hủy một phần, phê duyệt trùng.
Sản phẩm của Big Picture không phải là một bản thiết kế hoàn chỉnh. Mục tiêu là tìm ra địa hình miền sơ bộ, các đoạn phức tạp, thuật ngữ gây nhiều tranh cãi và các hotspot cần khám phá thêm. Dù thường bắt đầu từ phạm vi lớn, cần có khả năng chọn luồng có giá trị cao để mở rộng sang giai đoạn Process.
3.3 Process Level EventStorming
Giai đoạn Process là giai đoạn chọn một luồng cụ thể và gắn thêm lệnh, tác nhân, chính sách, mô hình đọc.
Trước sự kiện Đơn hàng đã được tiếp nhận, đặt lệnh Hãy tạo đơn hàng và tác nhân là khách hàng, đồng thời biểu thị việc tra cứu giỏ hàng cần thiết như một mô hình đọc.
Nhờ vậy, sự kiện không chỉ được liệt kê theo thời gian mà được cụ thể hóa thành luồng có ý định và trách nhiệm.
Chính sách được viết thành quy tắc lấy sự kiện làm nguyên nhân để tạo ra lệnh tiếp theo.
Với chính sách Khi thanh toán được phê duyệt thì yêu cầu xuất kho, người tham gia thảo luận đó là phản ứng tự động hay cần người phụ trách phê duyệt, có cần khoảng thời gian thử lại và khóa idempotency hay không.
Cuộc đối thoại này kết nối mô hình nghiệp vụ với thiết kế hệ thống phân tán, nhưng người điều phối phải giữ cân bằng để không vội vàng quyết định triển khai kỹ thuật.
Ở giai đoạn Process, thời gian, trách nhiệm và ngoại lệ được hỏi chính xác hơn. Các câu hỏi như đơn hàng đã được tạo chưa khi khách hàng đóng màn hình thanh toán, làm sao ngăn thanh toán trùng khi phản hồi phê duyệt chậm, ai thông báo cho khách hàng khi hãng vận chuyển từ chối hủy, được ghi lại bằng sự kiện và hotspot. Đặt đường đi bình thường và đường đi ngoại lệ trên cùng một màn hình giúp dễ đánh giá đó có phải luồng nghiệp vụ có thể vận hành được hay không.
sequenceDiagram
participant U as Khách hàng/Người phụ trách
participant O as Context đặt hàng
participant P as Context thanh toán
participant F as Context giao hàng
U->>O: Hãy tạo đơn hàng(Command)
O-->>O: Đơn hàng đã được tiếp nhận(Event)
O-->>P: Hãy yêu cầu phê duyệt thanh toán(Policy)
P-->>P: Thanh toán đã được phê duyệt(Event)
P-->>F: Hãy yêu cầu xuất kho(Policy)
F-->>F: Sản phẩm đã được xuất kho(Event)
F-->>O: Trạng thái giao hàng đã được cập nhật(Event)
O-->>U: Cung cấp mô hình đọc tình trạng đơn hàng
Chuỗi trên không ngụ ý một công nghệ cụ thể nào. Là API đồng bộ hay message broker, một cơ sở dữ liệu hay nhiều kho lưu trữ, sẽ được quyết định sau khi phân tích thêm về độ tin cậy, độ trễ và cơ cấu tổ chức. Tuy vậy, khi tách riêng sự kiện và chính sách, ta có ngôn ngữ chung để thảo luận về điểm gắn kết, lan truyền sự cố, thiết kế thử lại và bù trừ.
3.4 Giai đoạn Software Design
Ở giai đoạn Software Design, đoạn đã chọn ở giai đoạn Process được mở rộng thành các ứng viên aggregate, bounded context, dịch vụ, sự kiện và mô hình đọc.
Aggregate không phải là khái niệm gom mọi dữ liệu vào một bảng, mà là đơn vị trách nhiệm nghiệp vụ phải giữ tính nhất quán trong một giao dịch.
Không nên giả định đơn hàng và thanh toán luôn phải nằm trong một giao dịch, mà phải kiểm tra trước bất biến (invariant) và ranh giới thất bại của từng cái.
Bounded context trở thành ứng viên tại điểm mà cùng một từ bắt đầu mang nghĩa khác nhau. “Khách hàng” trong context đặt hàng có thể là chủ thể mua hàng có địa chỉ giao hàng, còn “khách hàng” trong context marketing có thể là đối tượng có phản hồi chiến dịch và phân khúc. Nếu gộp hai mô hình thành một đối tượng khách hàng khổng lồ, lý do thay đổi sẽ lẫn lộn và phải cưỡng ép điều chỉnh các quy tắc khác nhau.
Sự kiện giữa các context được quản lý như một hợp đồng công khai. Cần định nghĩa tên, trường dữ liệu, thời điểm phát sinh, khả năng trùng lặp, bảo đảm thứ tự, việc có chứa thông tin cá nhân hay không và thời gian lưu giữ của sự kiện. Thẻ trong workshop chưa phải là lược đồ sự kiện, nhưng là đầu vào để quyết định công khai sự thật nào ra bên ngoài và tách trách nhiệm nào.
4. Quan hệ giữa các thành phần mô hình và diễn giải thiết kế
4.1 Khác biệt giữa sự kiện, lệnh và chính sách
Lệnh là ý định chưa xảy ra, còn sự kiện là sự thật đã xảy ra. Lệnh có thể bị từ chối, nhưng sự kiện là việc đã xảy ra nên được ghi ở thì quá khứ. Chính sách là quy tắc quan sát sự kiện để tạo lệnh tiếp theo; khi điều kiện của chính sách thay đổi, hành động tiếp theo đối với cùng một sự kiện cũng có thể khác đi.
Ví dụ, lệnh Hãy áp dụng mã giảm giá là ý định do khách hàng hoặc hệ thống yêu cầu.
Nếu kiểm tra hợp lệ thành công, sự kiện Mã giảm giá đã được áp dụng xảy ra, và chính sách quan sát sự kiện này có thể tạo lệnh tiếp theo Hãy tính lại số tiền giảm giá.
Ngược lại, nếu mã giảm giá đã hết hạn thì lệnh bị từ chối, và có thể ghi riêng sự thật thất bại như Việc áp dụng mã giảm giá đã bị từ chối.
| Phân loại | Ý nghĩa | Góc nhìn thời gian | Sản phẩm thực tế |
|---|---|---|---|
| Lệnh | Yêu cầu về hành động mong muốn | Khả năng trong tương lai | Yêu cầu API, thông điệp hàng đợi tác vụ |
| Sự kiện | Sự thật nghiệp vụ đã xảy ra | Sự thật trong quá khứ | Sự kiện miền, bản ghi kiểm toán |
| Chính sách | Quy tắc nghiệp vụ phản ứng với sự kiện | Hành động tiếp theo có điều kiện | Process manager, quy tắc tự động hóa |
| Mô hình đọc | Thông tin tra cứu cần để phán đoán | Quan sát hiện tại | Màn hình, chỉ mục tìm kiếm, dashboard |
Sự phân biệt này quan trọng vì trách nhiệm và cách xử lý lại khác nhau. Lệnh phải kiểm tra quyền, tính hợp lệ và idempotency; sự kiện phải tính đến việc nhận trùng và đảo thứ tự. Chính sách phải thiết kế thử lại, bù trừ và sự can thiệp của con người khi thất bại; mô hình đọc phải quyết định cách thể hiện tính nhất quán cuối cùng (eventual consistency) có độ trễ cho người dùng.
4.2 Ranh giới và tính gắn kết
Ranh giới không phải là hành động kẻ đường giữa các thẻ, mà là quá trình quan sát mức độ gắn kết của quy tắc và ngôn ngữ. Những thành phần có lý do thay đổi đi cùng nhau, do cùng một nhóm chịu trách nhiệm và phải giữ cùng bất biến thì nhiều khả năng nằm trong một ranh giới. Ngược lại, nếu có thuật ngữ khác, tốc độ khác, trách nhiệm pháp quy khác thì dù có tích hợp vẫn có lý do để tách thành context riêng.
Tạo quá nhiều ranh giới sẽ làm tăng thông điệp và gánh nặng vận hành. Ngược lại, gộp tất cả vào một context sẽ làm mất khả năng triển khai độc lập và sự rõ ràng của mô hình. Do đó, ranh giới phải được quyết định bằng cách xem xét đồng thời năng lực nghiệp vụ, cơ cấu nhóm, quyền sở hữu dữ liệu và cô lập sự cố, chứ không dựa trên số lượng thẻ hay trào lưu microservice.
4.3 Ngoại lệ và bù trừ
Trong hệ thống thực tế, chi phí của ngoại lệ lớn hơn sự kiện bình thường. Sau khi phê duyệt thanh toán, tồn kho giao hàng có thể không đủ; sau khi yêu cầu giao hàng, API của hãng chuyển phát bên ngoài có thể tạm ngừng; người dùng cũng có thể yêu cầu hoàn tiền cho sản phẩm đã nhận. Những luồng như vậy không thể xử lý bằng một câu duy nhất “thất bại thì rollback”, mà cần sự kiện bù trừ để hoàn tác những sự thật đã lộ ra bên ngoài.
Trong workshop, không giấu ngoại lệ vào một hàng riêng mà dán gần dòng thời gian bình thường.
Nêu rõ các sự kiện mà khách hàng và người vận hành có thể quan sát, như Thanh toán không được phê duyệt, Yêu cầu xuất kho đã hết hạn, Hoàn tiền đã hoàn tất.
Sau đó đặt câu hỏi về chủ sở hữu, số lần thử lại, tiêu chí xử lý thủ công, thông báo khách hàng và vết kiểm toán của từng sự kiện.
5. So sánh và bối cảnh ứng dụng
5.1 So sánh với BPMN, UML, User Story
BPMN mạnh ở việc biểu diễn luồng quy trình nghiệp vụ, gateway, vai trò và thông điệp bằng ký hiệu chuẩn hóa. Biểu đồ tuần tự UML thể hiện rõ tương tác giữa các đối tượng, còn biểu đồ lớp thể hiện rõ cấu trúc và quan hệ. User Story phù hợp để quản lý giá trị người dùng và điều kiện chấp nhận. So với các phương pháp này, EventStorming ưu tiên khám phá chung nhanh chóng và làm lộ xung đột tri thức hơn là ký hiệu chính xác.
Vì vậy, thay vì so sánh EventStorming như vật thay thế BPMN, nên xem nó là hoạt động ở đầu chuỗi đi từ khám phá đến chuẩn hóa. Dựa trên sự kiện và hotspot đã thống nhất trong EventStorming, có thể cụ thể hóa luồng phê duyệt của BPMN, tương tác của UML và điều kiện chấp nhận của User Story. Ngược lại, nếu cần bằng chứng kiểm soát chính thức cho quy trình chịu quy định chặt chẽ thì tài liệu chuẩn hóa phải là sản phẩm cuối cùng.
| Góc nhìn | EventStorming | BPMN/UML | User Story |
|---|---|---|---|
| Mục đích chính | Cùng khám phá miền nghiệp vụ | Biểu diễn quy trình, cấu trúc chuẩn hóa | Quản lý giá trị và yêu cầu người dùng |
| Cách tham gia | Cộng tác đồng thời, lấy phát biểu làm trung tâm | Dễ xoay quanh người vẽ mô hình | Xoay quanh thảo luận sản phẩm và phát triển |
| Xử lý bất định | Hiện rõ bằng hotspot | Có thể chỉ còn là chú thích ngoài biểu đồ | Tách thành backlog, câu hỏi |
| Điểm mạnh | Hiểu chung nhanh và phát hiện ranh giới | Rà soát, truy vết, tự động hóa chính xác | Quản lý ưu tiên và tiêu chí chấp nhận |
| Hạn chế | Tính chuẩn hóa và tái lập có thể thấp | Nặng nề cho khám phá ban đầu | Có thể bỏ sót toàn bộ luồng nghiệp vụ |
Khi kết nối ba phương pháp, cần nêu rõ quy tắc chuyển đổi. Ví dụ, nếu sao chép máy móc tên sự kiện thành trạng thái trong BPMN thì có thể nhầm lẫn giữa sự kiện và trạng thái. Ngoài ra, các yêu cầu phi chức năng không có trên thẻ, căn cứ xử lý thông tin cá nhân, mục tiêu hiệu năng và thời gian lưu giữ phải được bổ sung bằng danh sách thuộc tính chất lượng riêng.
5.2 Kết nối với DDD, EDA, CQRS
EventStorming hữu ích trong thiết kế chiến lược của DDD để phát hiện bounded context và ngôn ngữ chung. Nó cũng có thể tạo ứng viên aggregate và sự kiện miền trong thiết kế chiến thuật, nhưng kích thước aggregate và ranh giới giao dịch phải được xác nhận lại qua mã nguồn và kiểm chứng bất biến.
Event-Driven Architecture (EDA) và Event Sourcing cũng có thể tận dụng khái niệm sự kiện của EventStorming. Tuy nhiên, không phải mọi thẻ được gọi là “sự kiện” trong workshop đều là sự kiện tích hợp được phát hành lên broker. Sự kiện miền để ghi nhận nghiệp vụ, sự kiện tích hợp giữa các hệ thống và sự kiện event sourcing để lưu trữ có thể khác nhau về mục đích, hợp đồng và chính sách lưu giữ.
Trong CQRS có thể tách mô hình lệnh và mô hình đọc, nhưng càng nhiều mô hình đọc thì độ trễ cập nhật và chi phí tái tạo càng lớn. Khi biểu thị mô hình đọc trong EventStorming, không chỉ đơn thuần lập danh sách màn hình mà phải ghi lại cả dữ liệu nào cần cho phán đoán nào và yêu cầu về độ mới của dữ liệu.
5.3 Tình huống hiện đại hóa hệ thống kế thừa
Giả sử một doanh nghiệp bán lẻ giả định đang hiện đại hóa hệ thống đặt hàng 15 năm tuổi.
Tài liệu hiện có ghi trạng thái đơn hàng là READY, PAYED, DELIVERY, DONE, nhưng người làm nghiệp vụ lại phân biệt nhiều trạng thái hơn: đơn hàng trước phê duyệt thanh toán, xuất kho một phần, tiếp nhận trả hàng, chờ hoàn tiền.
Nếu nhóm chia bảng thành dịch vụ trước, có nguy cơ sao chép nguyên ý nghĩa của các giá trị trạng thái cũ.
Trong EventStorming, người vận hành, nhân viên tư vấn và nhà phát triển mang các trường hợp khách hàng thực tế đến và sắp xếp sự kiện theo thời gian.
Kết quả có thể cho thấy Thanh toán đã được phê duyệt và Thanh toán đã được quyết toán là hai sự kiện khác nhau, và Giao hàng hoàn tất được chia thành thông báo của hãng vận chuyển và xác nhận nhận hàng của khách hàng.
Sự khác biệt này là câu hỏi nghiệp vụ phải giải quyết trước khi thiết kế ranh giới dịch vụ và hợp đồng dữ liệu.
Trong thiết kế tiếp theo, đặt hàng, thanh toán, giao hàng và trả hàng được xem là các ứng viên trách nhiệm độc lập, nhưng không phân rã ngay từ đầu thành bốn microservice. Sau khi kiểm chứng tần suất thay đổi, quyền sở hữu của nhóm, cô lập sự cố và yêu cầu nhất quán dữ liệu của từng context, mới tách dần từng bước. Như vậy, EventStorming không phải là công cụ cắt nhỏ hệ thống kế thừa nguyên trạng, mà là công cụ làm lộ khoảng cách giữa sự thật hiện tại và mô hình mục tiêu.
6. Điều phối và quản lý chất lượng
6.1 Vai trò của người điều phối
Người điều phối không phải là người đưa ra đáp án về miền, mà là người thiết kế luồng làm việc để người tham gia nói ra sự thật và xử lý xung đột một cách an toàn. Nếu ban đầu thuật ngữ kỹ thuật chi phối cuộc trò chuyện, hãy kéo câu hỏi trở lại “thực tế điều gì xảy ra trong nghiệp vụ này”. Dành thời gian viết thẻ cho người ít phát biểu, và dùng hotspot ẩn danh để ý kiến của người có cấp bậc cao không mặc nhiên trở thành đồng thuận.
Khung thời gian được vận hành theo từng giai đoạn. Ví dụ, đặt thời điểm kết thúc riêng cho việc thu thập toàn bộ sự kiện, sắp xếp dòng thời gian, bổ sung lệnh và tác nhân, phân loại hotspot, và chọn bước tiếp theo. Các mục tranh luận kéo dài được chuyển sang backlog câu hỏi riêng để việc học toàn bộ luồng không bị gián đoạn.
6.2 Các mẫu thất bại thường gặp
Thất bại thứ nhất là chỉ có nhà phát triển tham gia và viết sự kiện kỹ thuật như thể sự kiện nghiệp vụ.
Gọi API thành công, Hoàn tất Kafka publish có thể là sự thật quan sát hệ thống, nhưng không thấy mục đích nghiệp vụ và giá trị khách hàng nên phải phân biệt với sự kiện miền.
Thất bại thứ hai là lãnh đạo hoặc người lập kế hoạch áp đặt đáp án định sẵn lên thẻ.
Khi đó workshop chỉ còn hình thức đồng thuận, còn sự bất định thực tế bị che giấu.
Thất bại thứ ba là chuyển ngay mọi thẻ thành microservice. Màu sắc và ranh giới của thẻ là giả thuyết khám phá, nên nếu chốt ranh giới dịch vụ chỉ dựa trên lưu lượng hay số lượng nhóm thì giao dịch phân tán và gánh nặng vận hành sẽ tăng. Thất bại thứ tư là chỉ giữ luồng bình thường và để ngoại lệ “xử lý sau”. Nếu bổ sung muộn các luồng sự cố, hủy bỏ, bù trừ thì yêu cầu chất lượng thực tế bị thiếu và thiết kế vận hành bị đẩy xuống cuối giai đoạn triển khai.
6.3 Quản lý liên tục sản phẩm đầu ra
Bảng workshop không dừng lại ở một bức ảnh. Trích xuất các phần cần thiết thành từ điển sự kiện, nhật ký quyết định thuật ngữ, backlog hotspot, bản đồ context, bản ghi quyết định (ADR), hợp đồng API và sự kiện. Trong sản phẩm đầu ra, ghi lại ngày lập, phạm vi, người tham gia, giả định chưa giải quyết và công việc kiểm chứng tiếp theo để thành viên mới hiểu được mức độ tin cậy của mô hình.
Trong quá trình vận hành, kiểm tra xem sự cố và thay đổi thực tế có được phản ánh vào mô hình hay không. Nếu phát hiện ngoại lệ mới mà bảng không được cập nhật thì mô hình sẽ tách rời khỏi hệ thống hiện tại. Ngược lại, nếu chuyển mọi log thành thẻ thì ý nghĩa nghiệp vụ sẽ mờ đi, nên cần phân biệt sự thật đáng để chuyên gia miền quan sát với dữ liệu telemetry kỹ thuật.
7. Chuyên sâu: Cấu trúc bài làm và liên kết đề thi
Trong bài làm của Kỹ sư chuyên nghiệp (Professional Engineer), nếu chỉ định nghĩa EventStorming là “kỹ thuật họp bằng giấy ghi chú” thì chưa đủ chiều sâu. Sau định nghĩa, cần nêu nguyên nhân của sự phức tạp là silo tri thức, bất nhất thuật ngữ, trách nhiệm lẫn lộn trong hệ thống kế thừa, rồi giải thích cách khám phá lấy sự kiện làm trung tâm làm hiện rõ những vấn đề đó. Sau đó, liên kết các giai đoạn Big Picture→Process→Software Design, các thành phần màu sắc, hotspot và phát hiện ranh giới với sơ đồ khái niệm và tình huống thì mạch lập luận sẽ tự nhiên.
Với đề so sánh, không kết thúc khác biệt với BPMN, UML, User Story bằng bảng đơn thuần, mà nêu bối cảnh “giai đoạn khám phá và giai đoạn chuẩn hóa là khác nhau”. Khi liên kết với EDA, DDD, CQRS, cần đưa vào lưu ý không đồng nhất sự kiện trong workshop với sự kiện tích hợp. Cuối cùng, tổng hợp các lưu ý gồm thiên lệch khi điều phối, bỏ sót ngoại lệ, cập nhật sản phẩm đầu ra, và quản lý riêng yêu cầu về thông tin cá nhân và bảo mật.
Tình huống ví dụ nên dùng luồng quen thuộc như đặt hàng, thanh toán, nhưng đưa vào thanh toán chậm, hoàn tiền một phần, lỗi tích hợp bên ngoài để thể hiện tính thực tế của hệ thống phân tán.
Nếu cần số liệu, hãy nêu ví dụ vận hành thông thường như một phiên Process nhỏ gồm 610 người tham gia trong 23 giờ, và không phóng đại thành thành tích của một tổ chức cụ thể.
Kết luận của bài làm nên quy về “hiệu quả sẽ bền vững khi phát hiện ranh giới qua học tập chung và kết nối với sản phẩm chuẩn hóa và quản trị vận hành”.
8. Lưu ý và hàm ý
8.1 Kiểm soát phạm vi và mục đích
Nếu phạm vi quá rộng, thẻ chỉ chồng chất mà không đưa ra được quyết định. Cần chọn một trong hành trình khách hàng, năng lực nghiệp vụ hoặc một luồng sự cố cụ thể, và làm rõ điều kiện bắt đầu và kết thúc. Ngược lại, nếu thu hẹp phạm vi quá mức thì không thấy được trách nhiệm giữa các context và ảnh hưởng bên ngoài, vì vậy cần cách tiếp cận phân tầng: nhìn rộng ở Big Picture và thu hẹp ở Process.
8.2 Người tham gia và an toàn tâm lý
Tri thức miền không bị độc quyền bởi một vị trí công việc. Nhân viên tư vấn biết ngoại lệ và khiếu nại, người vận hành biết sự cố và xử lý thủ công, nhà phát triển biết ràng buộc hệ thống, nên phải cùng mời họ tham gia. Điều quan trọng là phân biệt sự thật, giả định và ý kiến để phát biểu của người cấp cao không bị đóng khung thành chân lý của mô hình, và vận hành sao cho bất đồng được lưu lại an toàn dưới dạng hotspot.
8.3 Tính nhất quán và khả năng truy vết
Mô hình thẻ nhanh nhưng tính chuẩn hóa thấp, nên thuật ngữ và quyết định đã thống nhất phải được truy vết qua từ điển sự kiện, ADR, yêu cầu và kiểm thử. Nếu tên sự kiện thay đổi trong API hay log thì phải kiểm tra phạm vi ảnh hưởng, và xác định một chuẩn duy nhất trong kho lưu trữ về mô hình nào là mới nhất. Không che giấu khác biệt giữa mô hình và triển khai, mà ghi lại lý do và thời hạn hiệu lực của khác biệt đó.
8.4 Chất lượng hệ thống phân tán
Nếu tiếp nối bằng thiết kế hướng sự kiện, bắt buộc phải kiểm tra trùng lặp, đảo thứ tự, độ trễ, thất bại một phần, xử lý lại và idempotency. Dù workshop giải thích ý nghĩa nghiệp vụ, nó không tự động giải quyết bảo đảm truyền tải của mạng hay sự cố của broker. Cần thiết kế thử lại, DLQ, bù trừ, khả năng quan sát (observability) và log kiểm toán cho từng chính sách, đồng thời quyết định cách thông báo tính nhất quán cuối cùng cho khách hàng.
8.5 Thông tin cá nhân và bảo mật
Nếu ghi giá trị thực của định danh khách hàng, thông tin sức khỏe, thông tin thanh toán lên thẻ, chính bảng workshop sẽ trở thành kho lưu trữ thông tin cá nhân. Cần dùng bút danh hoặc giá trị ví dụ thay cho dữ liệu thật, và áp dụng chính sách quyền truy cập, thời gian lưu giữ, tải xuống cho bảng số. Hợp đồng sự kiện phải được liên kết riêng với các yêu cầu phi chức năng như thu thập tối thiểu, giới hạn mục đích, kiểm soát truy cập, mã hóa và vết kiểm toán.
8.6 Cải tiến bền vững
Không kỳ vọng mô hình hoàn chỉnh chỉ sau một workshop. Cần điều tra hotspot, phản ánh chỉ số vận hành thực tế và phản hồi khách hàng, và thực hiện các phiên khám phá lại ngắn khi có thay đổi quan trọng. Kết nối tài liệu onboarding với kho lưu trữ để tri thức được duy trì qua ngôn ngữ chung và bản ghi quyết định ngay cả khi nhóm thay đổi, đó chính là quản trị từ góc nhìn Kỹ sư chuyên nghiệp.
Tài liệu tham khảo
- Trang chính thức EventStorming, Alberto Brandolini: https://www.eventstorming.com/
- Tài nguyên chính thức EventStorming: https://www.eventstorming.com/resources/
- Avanscoperta, Introducing EventStorming: https://blog.avanscoperta.it/2014/02/12/introducing-event-storming/
- Open Group Open Agile Architecture, Event Storming Workshop: https://pubs.opengroup.org/architecture/o-aa-standard/event-storming-workshop.html
- VMware Tanzu, Event Storming: https://blogs.vmware.com/tanzu/event-storming/
Tóm tắt một câu: EventStorming là phương pháp khám phá mang tính cộng tác, cùng nhau trải các sự kiện miền lên trục thời gian để phát hiện ngôn ngữ, quy tắc, ngoại lệ và ranh giới của nghiệp vụ phức tạp, rồi kết nối kết quả đó với DDD, EDA, mô hình chuẩn hóa và quản trị vận hành.