• Không đạt yêu cầu nghiệp vụ.
• Chậm tiến độ.
• Quản lý dự án kém.
• Chất lượng sản phẩm kém.
• Vượt quá ngân sách.

Giao tiếp là yếu tố tiên quyết trong phát triển phần mềm. Domain experts chia sẻ kinh nghiệm nghiệp vụ với nhà phát triển. Không chỉ vậy, trong quy trình phát triển, nhiều bên liên quan cùng tham gia với các vai trò khác nhau: Domain Experts, Product Owners, Engineers, UI&UX Designer, v.v. Hợp tác giữa họ quyết định chất lượng công việc chung. Nghiên cứu về lý do các dự án phần mềm thất bại đã chỉ ra rằng giao tiếp hiệu quả là yếu tố then chốt cho việc chia sẻ kiến thức và thành công của dự án. Tuy nhiên, mặc dù giao tiếp hiệu quả rất quan trọng, nó lại hiếm khi được quan sát thấy trong các dự án phần mềm. Thông thường, các nhân sự nghiệp vụ và kỹ thuật không có sự tương tác trực tiếp với nhau. Thay vào đó, yêu cầu nghiệp vụ hay tri thức nghiệp vụ được truyền đạt từ domain experts đến kỹ thuật viên thông qua những người trung gian như PO, PM, BA. 

Những yêu cầu ban đầu được phát biểu mang tính thuần khiết nghiệp vụ, qua nhiều bước được "phiên dịch" thành ngôn ngữ của lập trình viên. Mặc dù nó giúp cho lập trình viên không cần nắm quá sâu nghiệp vụ nhưng đây là quá trình mà tri thức có thể bị rơi rớt. Bạn nói với người này, người này nói với người khác, người khác lại nói với người khác nữa. Cứ thế, nội dung truyền đạt ban đầu của bạn sẽ dần mai một và sai khác đi. Hãy nhớ rằng, sản phẩm phần mềm cuối cùng chính là ý hiểu của lập trình viên.

Vậy làm thế nào để chúng ta thu hẹp khoảng cách này, đảm bảo rằng ý tưởng của domain experts được chuyển hóa thành sản phẩm một cách chính xác nhất, và tất cả các bên liên quan đều "nói cùng một ngôn ngữ"? Đây chính là lúc chúng ta cần đến sức mạnh của Ubiquitous Language và EventStorming.

EventStorming

Alberto Brandolini lần đầu giới thiệu và công bố ý tưởng về EventStorming vào năm 2012 tại Italian Agile Day. Thuật ngữ này được ông đặt tên chính thức vào 2013. Bài blog "Introducing EventStorming" của ông được đăng vào tháng 2/2014 giúp phổ biến rộng rãi phương pháp này. Và hiện tại, sau vài năm, dự án viết cuốn sách cùng tên của ông vẫn chưa hoàn thành.

EventStorming là một kỹ thuật hợp tác giữa các bên liên quan trong dự án phần mềm nhằm khám phá, phân tích và mô hình hóa nghiệp vụ. Trong quá trình này, các sự kiện (events), yêu cầu (commands), nhân tố thực thi (actors), và các thực thể nghiệp vụ được xác định thông qua trao đổi giữa các bên. Phương pháp này được sinh ra từ kinh nghiệm áp dụng DDD của ông.

Tại sao lại là “khám phá”?

Từ “khám phá” hay “discover” được sử dụng trong “khám phá miền nghiệp vụ - discover domain” vì:

• Miền nghiệp vụ vốn đã tồn tại, đúng đó đó nhưng nó chưa được hiểu rõ. 
  Các quy trình, quy tắc, và thực thể nghiệp vụ đã tồn tại trong thực tế hoạt động của doanh nghiệp. Tuy nhiên, chúng thường không được mô tả rõ ràng hoặc thống nhất giữa các bên liên quan. Từ “khám phá” ám chỉ quá trình “khai quật” kiến thức ẩn, giống như tìm kiếm một kho báu đã có sẵn nhưng chưa được vẽ bản đồ.
  Ngoài ra, miền nghiệp vụ còn tồn tại độc lập với hệ thống phần mềm. Đó là cách doanh nghiệp vận hành, như merchant tạo sản phẩm hay customer đặt hàng. “Khám phá” phù hợp vì đội phát triển không thiết kế domain từ đầu mà khám phá để đảm bảo mô hình phần mềm phản ánh chính xác thực tế.
• Tính chất khám phá trong DDD.
  Trong DDD, khám phá domain là quá trình hợp tác giữa các chuyên gia nghiệp vụ và đội kỹ thuật để xây dựng ubiquitous language và mô hình hóa domain. Từ “khám phá” nhấn mạnh rằng đội ngũ không “tạo ra” domain mà học hỏi và làm rõ nó.
• Phản ánh tính không chắc chắn và học hỏi.
  “Khám phá” còn phản ánh sự không chắc chắn trong quá trình làm việc với domain nghiệp vụ phức tạp. Các bên liên quan có thể có hiểu biết khác nhau về cùng một quy trình. EventStorming giúp “khám phá” sự thật chung qua thảo luận.
  

Đặc điểm

EventStorming là buổi họp hay hội thảo low-tech mà ở đó có những thứ có thể bạn sẽ không hình dung tới:

• Công cụ thực hiện: Một bảng trắng hoặc như tác giả Brandolini có nói có những buổi ông đã kết thúc buổi workshop với 20m giấy trắng dán tường (thay cho bảng trắng). Các stickey note với những màu sắc khác nhau, đại diện cho những loại thông tin khác nhau của domain, cùng những chiếc bút dạ mà bạn thường gặp.

•  Không gian: Bạn sẽ hình dung có một cái bàn lớn ở giữa với các ghế ngồi xung quanh? Không, ông đã tiến hành các buổi này bằng cách loại bỏ hoặc di chuyển hết ghế ngồi và bàn. Điều này sẽ khiến những người tham gia đều đứng (vì khi ngồi, sự tích cực bổ sung ý kiến sẽ giảm đi) trong một căn phòng đủ lớn.
• Thành viên tham gia: Đại diện cho tất cả các bên liên quan tới nội dung của buổi họp. Dưới đây là các bên quan trọng nhất:
  • Domain experts cung cấp kiến thức sâu rộng về domain, giúp xác định các sự kiện chính, các quy tắc nghiệp vụ và các yếu tố quan trọng nhất trong domain.
  • Product owners có thể đứng trên phương diện khách hàng hay end-user, chịu trách nhiệm đảm bảo rằng ứng dụng sẽ đáp ứng đúng yêu cầu nghiệp vụ. Họ còn đưa ra độ ưu tiên của chức năng xây dựng.
  • Architects và developers tích cực làm rõ yêu cầu, qua đó làm căn cứ thiết kế và phát triển hệ thống qua các đóng góp về giải pháp kỹ thuật, đưa ra các câu hỏi để làm rõ các yêu cầu và đảm bảo rằng hệ thống đáp ứng được các yêu cầu nghiệp vụ trên một kiến trúc mạnh mẽ, phù hợp.
  • Business analysts (BA) đóng vai trò cầu nối giữa nghiệp vụ và giải pháp kỹ thuật, thực hiện phân tích, mô hình hóa yêu cầu, đảm bảo hệ thống đáp ứng dúng yêu cầu nghiệp vụ.
• Ngôn ngữ sử dụng: Mọi người được khuyến khích sử dụng ngôn ngữ nghiệp vụ. Do đó, các từ khóa thông thường sẽ được xuất phát từ chuyên gia nghiệp vụ, khách hàng và được các bên khác học hỏi.

Phân loại

Thông thường, EventStorming được phân thành hai loại chính: Big Picture và Design Level.

• Big Picture. Nếu bạn gặp khó khăn hay vấn đề với quy hoạch hệ thống, ranh giới giữa các microservices thì đây có thể là một công cụ mạnh mẽ để bạn thực hiện tốt hơn. Giai đoạn Big Picture mang tới cái nhìn tổng quan về domain hệ thống. Qua đó, giúp ta phân chia hệ thống thành các thành phần nhỏ hơn như subdomain và bounded context và mối quan hệ giữa chúng. Big Picture được thực hiện ở giai đoạn đầu dự án.
• Design Level: Công việc mà bạn có thể vẫn thường làm, đó là tập trung vào phân tích, thiết kế một microservice. Design Level cũng vậy, nó thường tập trung vào một sudomain hay bounded context đã có trong Big Picture. Nếu như ở Big Picture, bạn thấy một số event hay aggregate quan trọng thì tại đây bạn sẽ thấy nhiều hơn, những thức vây quanh lại thành phần quan trọng kia, chúng hoàn thiện những hành động nhỏ, những use case nhỏ, đặc thù của phạm vi mà chúng phụ trách. Kết quả đầu ra mà tôi lựa chọn chính là tài liệu thiết kế chi tiết có thể mang đi triển khai thực tế.

Cách vận hành

Chủ trì (Facilitator) là người dẫn dắt và điều phối buổi Event Storming, đảm bảo rằng buổi làm việc diễn ra hiệu quả và đạt được mục tiêu đề ra. Các hành động chính:

• Chuẩn bị. Xác định mục tiêu và lên kế hoạch cho buổi họp. Chuẩn bị các công cụ như bảng, giấy ghi chú, but màu hoặc các công cụ trực tuyến. Cuối cùng, mới các bên liên quan tham gia họp.
• Giới thiệu. Mô tả mục tiêu, phạm vi, và các quy tắc của buổi họp.
• Điều phối, dẫn dắt. Dẫn dắt cuộc họp, đảm bảo bên nào cũng có quyền phát biểu, đồng thời giải quyết bất đồng nếu có. Đảm bảo buổi họp được tập trung và hiệu quả.
• Quản lý thời gian.
• Tóm tắt, kết luận. Cuối buổi họp, chủ trì cần tóm tắt lại những gì đã thảo luận và đồng ý. Các kết quả này (bao gồm cả ảnh chụp bảng, giấy ghi chú) được ghi lại một cách rõ ràng và chia sẻ tới tất cả các bên liên quan sau buổi làm việc.

Người chủ trì của một buổi Event Storming không nhất thiết phải thuộc một bộ phận cụ thể. Tuy nhiên, để đảm bảo tính khách quan, chủ trì thường là người không trực tiếp tham gia vào việc phát triển hoặc quyết định nghiệp vụ của dự án. Họ có thể đến từ một bộ phận hỗ trợ, quản lý dự án, hoặc thậm chí là một bên thứ ba, với nhiệm vụ điều phối buổi làm việc và tạo điều kiện cho sự hợp tác giữa các bên liên quan. Do đó, chủ trì có thể là một người trung lập trong nhóm để giảm khả năng thiên vị hoặc bị ảnh hưởng quá nhiều bởi một khía cạnh nào đó của dự án. Điều này giúp họ có thể dẫn dắt buổi làm việc một cách công bằng, hiệu quả. Ngoài ra, đó có thể là một chuyên gia về Event Storming. Họ hiểu biết sâu rộng về các kỹ thuật, công cụ và quy trình liên quan để điều phối cuộc họp.

Vận hành cụ thể trong buổi họp:

• Người điều phối khuyến khích mọi người tự do đóng góp ý tưởng, không phán xét, để khai thác kiến thức ẩn từ domain.
• Các sticky notes đại diện cho từng loại thông tin lần lượt được dán lên tường qua từng chủ đề nhỏ. Những chủ đề có thể là “những sự kiện chính xảy ra trong hệ thống”, “những hành động nào tạo ra những sự kiện này?”, hay “ai là người thực hiện”,… 
• Đôi khi, có những tình huống làm mọi người băn khoăn hoặc thấy vấn đề khiến tất cả phải chú ý và có thể cùng đưa ra giải pháp, hoặc ít nhất là đánh dấu nó với một màu sắc đặc trưng (màu tím). Vấn đề đó có thể là “làm thế nào để tạo đơn hàng không bị báo lỗi hết tồn kho?”.
• Nguyên tắc xuyên suốt buổi họp là tập trung vào domain events phản ánh nghiệp vụ, như ProductCreated, StockReceiptCreated, thay vì các thuật ngữ nghiệp vụ. Do đó, buổi họp tập trung vào khám phá chứ không phải thiết kế giải pháp kỹ thuật ngay.
• Kết quả cuối cùng được ghi nhận, tại đó có những điểm đồng thuận và có những điểm cần làm rõ sau.

Tinh thần của EventStorming

Như chính tác giả Alberto Brandolini đã nhấn mạnh, Event Storming không có các quy tắc vận dụng cứng nhắc. Nó là một phương pháp "low-tech" và linh hoạt, đề cao việc học hỏi nhanh nhất có thể trong thời gian ngắn nhất. Thành công của nó không nằm ở việc tuân thủ từng bước một cách máy móc, mà ở việc nắm vững tinh thần cốt lõi: khuyến khích khám phá, hợp tác, và xây dựng sự hiểu biết chung thông qua ngôn ngữ nghiệp vụ xoay quanh các sự kiện.

Event Storming không chỉ là một công cụ phân tích; nó là một triết lý về cách chúng ta làm việc cùng nhau để giải quyết các bài toán nghiệp vụ phức tạp, đảm bảo rằng sản phẩm phần mềm cuối cùng thực sự là một giải pháp chính xác và giá trị cho người dùng.

Giờ hãy cùng áp dụng EventStorming cho bài toán của chúng ta.