Xàm xí về Domain Driven Design - Part 2: What? and Why Domain Driven Design?

- 15 mins

Bài trước mình đã chia sẻ những cơ duyên mình đến với DDD và coi DDD như một kim chỉ nam để sống vui vẻ hạnh phúc trong việc phát triển phần mềm. Bài viết này chúng ta sẻ cùng thảo luận những nội dung chính sau:

1. What is Domain?

Ngày trước mình cũng lùng bùng bên tai khi nghe từ này, chẳng hiểu chính xác nó là gì. Đơn giản không thể hiểu vì bản chất từ này mang một ý nghĩa rất rộng, Domain là tất cả những gì mà một tổ chức đã, đang và sẻ làm và thế giới mà tổ chức đó thuộc về.

Như chúng ta đều biết, các doanh nghiệp/tổ chức sẻ xác định thị trường và bán sản phẩm, dịch vụ của họ. Mỗi tổ chức, doanh nghiệp sẻ có các bí quyết và cách thức riêng biệt để thực hiện các thứ liên quan đến thị trường và sản phẩm dịch vụ của họ. Ví dụ như KFC sinh ra để cung cấp cho người tiêu dùng những bữa ăn nhanh, nhằm thoả mãn nhu cầu ăn uống cho những người bận rộn. Tiki hướng đến việc cung cấp một Marketplace để phục vụ người mua và người bán. Grab cung cấp một giải pháp kinh tế chia sẻ giữa tài xế, cửa hàng tiện ích, người đi mua hàng, người bán dịch vụ, người có nhu cầu đi lại….nhằm tối ưu hoá các hoạt động đi lại, mua sắm, vận chuyển….

Tổng hợp của sự hiểu biết về thị trường hiểu biết về người dùng, quan hệ giữa các loại thực thể trong thế giới mà các doanh nghiệp đó muốn xây dựng nên, cộng với các phương pháp cách thức mà các doanh nghiệp đó tạo ra sản phẩm dịch vụ của họ sẻ được gói gọn bằng từ Domain.

2. What is Domain Driven Design? Why we need Domain Driven Design?

Việc phát triển một hệ thống lớn và phức tạp thật sự là một quá trình khó khăn và đau đơn. Từ phía đội ngủ quản lí, phía các engineers lẫn các stackholders liên quan khác đều có các vấn đề nan giải riêng.

a. Đứng dưới góc độ là một nhà quản lí:

b. Đứng dưới góc độ là một Architect/Technical Expert lẫn engineer:

c. What is root cause?

Markdowm Image

Các vấn đề liệt kê trên chỉ là một số ít thử thách trong quá trình phát triển phần mềm thôi. Trong thực tế còn nhiều thứ đáng lo hơn nhiều. Vậy tất cả chúng đa số bắt nguồn từ đâu?

Thực tế các thử thách khó khăn đa phần đến từ complexity, đến từ chuyện có quá nhiều concerns quá nhiều thứ làm chúng ta distract.

Để giải quyết các vấn đề trên bắt buộc chúng ta không còn cách nào khác là phải liên tục giảm độ phức tạp, tăng cường đàm phán loại bỏ các yếu tố gây nên sự phức tạp dựa trên nguyên tắc 80-20. Đồng thời đào sâu làm rõ kiến thức về Domain. Đó cũng là triết lý đầu tiên mà tác giả Eric Evans giới thiệu trong cuốn sách của ông ấy từ năm 2003.

d. Domain Driven Design

Markdowm Image

DDD về cơ bản là một tập hợp các principles, parterns hướng đến việc thấu hiểu domain và khám phá các giá trị business. Từ đó tạo ra các model giàu ý nghĩa của domain đó đồng thời liên tục làm giàu và tôi luyện Ubiquitous Language, tự nhiên ắt sẻ giúp chúng ta thoả mãn các vấn đề kể trên sống vui vẻ hạnh phúc trong ngành phần mềm:

3. What is the Ubiquitous Language?

Markdowm Image

Để có thể phát triển một phần mềm cho một Domain cụ thể ít nhất chúng ta cần một cách mô tả Domain này. Viêc chỉ có một relational data model truyền thống hay thứ gì đó tương tự thực sự là không đủ. Chúng ta cần có khả năng mô tả không chỉ các đối tượng và mối quan hệ của chúng mà phãi mô tả những thứ khác linh động hơn như events, event flow, processes, business invariants, cách mà các đối tượng thay đổi theo thời gian… Chúng ta cần có thể thảo luận và phản biện về Domain với cả các developer lẫn các domain expert/BA. Những gì mà chúng ta cần đó được là Ubiquitous Language.

Ubiquitous Language là một ngôn ngữ thống nhất được cả Domain Expert và Developers sử dụng để mô tả và thảo luận về Domain. Ngoài code ra thì Ubiquitous Language là trọng nhất của Domain Driven Design proccess. Chúng ta có thể document lại Ubiquitous Language theo nhiều cách khác nhau, ban đầu là phãi tạo ra các thuật ngữ thống nhất giữa developer mà domain expert. Các Business Logic, relationship có thể được mô tả bằng các domain specific languages, diagrams and flow charts, UML, Finite state machine, Data Flow, Event Storming….Đôi lúc có một số nhu cầu nhỏ, nhanh gọn chúng ta có thể sử dụng các domain specific languages build sẳn, cá nhân bản thân mình thấy đối với một team nhỏ tầm 6-9 người thì một Domain Specific Language như DSL của GOA thì cũng đủ sài cho các bên liên quan.

4. Big picture about Domain Driven Design:

Về DDD chủ yếu giúp chúng ta giải quyết sự complexity dựa trên ba công cụ chính:

A. Strategic Modeling:

Thiết kế các Enterprise Software cần được thực hiện một cách khôn ngoan và hợp lí, Strategic Modeling là tập hợp các cách tiếp cận nhằm giúp chúng ta mô hình hoá một hệ thống cho phép chúng ta có khả năng chia để trị domain lớn, lập kế hoạch cho tương lai cũng như đưa ra quyết định phù hợp với sứ mệnh và giá trị cốt lõi của domain mà chúng ta muốn làm.

Strategic Modeling tập trung vào việc define cũng như sử dụng các Bounded Context, SubDomain, quản lí ngữ nghĩa của các concepts giữa các context khác nhau… đồng thời rất hữu ích để trong việc cung cấp các khía cạnh phản biện, tranh luận để tìm ra một strategic architecture tốt phù hợp với domain chúng ta hướng tới.

Việc có một bản Context Map và các khái niệm cốt lõi chung giúp chúng ta dễ dàng improve bức tranh tổng quan của toàn hệ thống. Đặc biệt đối với Microservices approach, Strategic Modeling giúp chúng ta define và kết nối các service một cách đúng đắn tuân theo nguyên tắc low coupling, high cohesion bằng cách xác định các Bounded Context, Subdomain một cách phù hợp.

B. Tactical Modeling:

Đây sẻ là cách mà chúng ta mô hình hoá một cách có đường hướng chiến thuật trong các Bounded Context bằng cách sử dụng các building block partern của DDD như Aggregate, Repository, Factory, Services, Domain Event và các khái niệm liên quan như Entity, Value Objects,… để design các module một cách đúng đắn nhất

C. Các Parterns/Architectures:

Có chiến thuật, có model rồi, chúng ta cần nhạy bén tuỳ vào các yêu cầu mục đích cụ thể mà chọn các mẫu architecture phù hợp ví dụ như Clean Architecture, CQRS/Event Sourcing,… sao cho vừa thoả mãn business đồng thời dễ dàng mở rộng thêm tính năng cũng như tối thiểu hoá chi phí maintain.

5. Conclusion:

Tin học mà, tin rồi mới học. Nếu bạn tin rằng chúng ta sẻ có thể sống vui vẻ hạnh phúc trong ngành phần mềm nhờ vào DDD rồi thì ngại gì không đào sâu nó nào.

Bài tiếp theo mình sẻ nói về công cụ đầu tiên và quan trọng nhất của Domain Driven Design - Strategic Modeling.

comments powered by Disqus
rss facebook twitter github gitlab youtube mail spotify lastfm instagram linkedin google google-plus pinterest medium vimeo stackoverflow reddit quora quora