Event storming và Domain driven design

Một số hiểu biết sai lầm về microservice

• Microservice là chia thành nhiều module với nhiều công nghệ khác nhau.

• Là giải pháp về mặt công nghệ

• Microservice giúp giải quyết các vấn đề liên quan đến hiệu năng

Vậy microservice là gì

Theo định nghĩa về microservice của Martin Fowler, thì microservice mang một số đặc điểm:

• Tập trung giải quyết 1 vấn đề

• Gắn với 1 nghiệp vụ cụ thể

• Tự chủ

• Triển khai độc lập

• Kết nối lỏng lẻo (loosely-coupled)

Bắt đầu microservice từ đâu

• Microservice là giải pháp về mặt nghiệp vụ nên phải luôn bắt đầu từ nghiệp vụ

• Để xác định chia các microservice hiệu quả, thì nên xác định được các bounded context (bên dưới), từ đó đưa ra quyết định hợp lý.

Domain-driven design

Domain Driven Design (DDD) là tập hợp của một số chuẩn mực kiến trúc (architectural pattern) được bác Eric Evans giới thiệu trong cuốn “Domain-Driven Design: Tackling Complexity in the Heart of Software” từ những năm 2002 và được sử dụng rộng rãi trong thiết kế các hệ thống thông tin hiện đại theo kiến trúc Microservices và Event-Driven.
Trong DDD có 2 bước chính, bước 1 là Strategic design và bước 2 là Tactical design. Trong đó bước 1 giúp xác định nghiệp vụ, các domain và subdomain từ đó cho ra bounded context và các mối liên hệ giữa các bounded context. Còn bước 2 lại đi sâu hơn về mặt giải pháp thiết kế từ output của bước 1 là các bounded context. Trong khuôn khổ buổi off, nhóm chỉ mới đi tìm hiểu bước 1.
Ở bước strategic design (bước 1), có 1 số khái niệm:

• Domain: là lĩnh vực hoặc phạm vi vấn đề mà hệ thống phần mềm được thiết kế để giải quyết. Đây là "bức tranh lớn" bao gồm tất cả các khía cạnh liên quan đến vấn đề kinh doanh hoặc nghiệp vụ. Ví dụ trong một công ty thương mại điện tử, Domain có thể là Thương mại điện tử (E-commerce).

• Subdomain là các phần nhỏ hơn hoặc các lĩnh vực con của Domain, phản ánh các chức năng cụ thể hoặc các khía cạnh chi tiết hơn của vấn đề tổng thể. Có 3 loại subdomain là core domain (phần lõi) tạo giá trị lợi thế cạnh tranh cho doanh nghiệp, supporting domain là phần hỗ trợ cung cấp chức năng cần thiết cho Core subdomain và cuối cùng là generic domain là phần không độc nhất hoặc thường được tiêu chuẩn hóa hay mua ngoài như là hệ thống xử lí thanh toán.

• Bounded Context: là ranh giới mà trong đó một mô hình cụ thể được áp dụng và có ý nghĩa. Nó xác định một không gian nơi các khái niệm, ngôn ngữ, và logic nghiệp vụ cụ thể được thống nhất và không bị xung đột với các ngữ cảnh khác. Bounded Context không phải là Subdomain. Ví dụ trong một số hệ thống, thanh toán có thể không được coi là một Subdomain độc lập mà chỉ là một phần của một Subdomain lớn hơn (ví dụ: Quản lý đơn hàng), thanh toán lúc đó nên được coi là bounded context.

• Domain event: là 1 sự kiện xảy ra trong nghiệp vụ (ví dụ: khi order được đặt)

Event storming

• Event storming là 1 buổi thảo luận giữa dev, BA, Domain expert, và các thành viên khác, tất cả tập trung vào xây dựng flow của domain event, và domain process

• Các thiết kế UML hay BPMN quá cụ thể và cần nhiều kiến thức chuyên môn nên sẽ không phù hợp với giai đoạn bắt đầu tìm hiểu business

• Thiết kế với Structural modeling lấy data và domain model làm trung tâm (như E-R diagram) tuy nhiên nó khá khó để xác định bounded context. anh em dev thì khá quen với kiểu này. Bước này nên được xử lí ở bước Tactical design.

• Event storming tiếp cận theo hướng temporal modeling, luồng nghiệp vụ sắp xếp theo hướng thời gian, lấy Domain Event làm trung tâm từ đó xác định ra bounded context.

  

Event storming có 3 cấp độ:

• Big picture: Big Picture là các thành viên cùng nhau kể một câu chuyện chung, mọi khía cạnh của câu chuyện đều phải được “hiện hình” (visible) cho dù đó là những quan điểm bị xung đột hay những khó khăn mà chưa có giải pháp ở thời điểm hiện tại.

• Process level: chi tiết hơn ở từng flow, cần sự tham gia chặt chẽ của cả người làm tech và những người làm business.

• Design level: tập trung vào kĩ thuật và triển khai cụ thể.

Các thuật ngữ sử dụng trong event storming:

• Domain event: sự kiện (ví dụ: OrderPlaced)

• Command: hành động của tác nhân (ví dụ Place Order)

• Actor: tác nhân (vd: người mua hàng)

• Read Model: thông tin để tác nhân ra quyết định (ví dụ thông tin chi tiết sản phẩm)

• Policies: rule để hành động được chấp thuận (ví dụ 18+)

• Boundaries: biên giới khoanh vùng bounded context

Tham khảo:

• sách Learning Domain-Driven, Design Aligning Software Architecture and Business Strategy

• sách Monolith to Microservices, Evolutionary Patterns to Transform Your Monolith

• tổng hợp bài viết hay và chi tiết từ Principal engineer Vinfast https://github.com/hongsan/random/discussions

• một ví dụ hoàn chỉnh về event storming: https://miro.com/app/board/uXjVMt80cUw=/