Báo cáo Đồ án 1: Thực hành Domain-Driven Design - SV. Trần Tuệ Tánh

Tài liệu đồ án thực hành Domain-Driven Design (DDD) từ lý thuyết đến ví dụ thực tế, phân tích các khái niệm Strategic & Tactical Design.

• Tác giả: Trần Tuệ Tánh
• Người hướng dẫn: ThS. Nguyễn Công Hoan
• Trường học: Trường Đại học Công nghệ Thông tin, Đại học Quốc gia Thành phố Hồ Chí Minh
• Chuyên ngành: Công nghệ Phần mềm
• Đề tài: Thực hành Domain-Driven Design
• Loại tài liệu: Báo cáo đồ án
• Năm xuất bản: 2024
• Địa điểm: Thành phố Hồ Chí Minh

Tóm tắt

I. Domain Driven Design là gì và Lịch sử Phát triển

Domain-Driven Design (DDD) là một phương pháp phát triển phần mềm được giới thiệu bởi Eric Evans vào năm 2003 thông qua cuốn sách nổi tiếng "Domain-Driven Design: Tackling Complexity in the Heart of Software". DDD tập trung vào việc mô hình hóa và hiểu sâu về các miền (domain) của nghiệp vụ, giúp giải quyết sự phức tạp trong các hệ thống phần mềm hiện đại. Phương pháp này nhấn mạnh sự kết hợp chặt chẽ giữa kỹ thuật lập trình và các yêu cầu nghiệp vụ, cho phép các nhóm phát triển hiểu rõ hơn về phạm vi và các vấn đề của miền mà họ đang làm việc. Domain-Driven Design đã trở thành một hướng tiếp cận quan trọng để xây dựng các hệ thống phần mềm phức tạp một cách hiệu quả và bền vững.

1.1. Khái niệm cơ bản của Domain Driven Design

Domain-Driven Design là một phương pháp tiếp cận hệ thống với mục tiêu tạo ra một mô hình phản ánh đúng các yêu cầu nghiệp vụ. DDD không chỉ là một tập hợp các công cụ kỹ thuật, mà còn là một triết học thiết kế nhấn mạnh tầm quan trọng của ngôn ngữ chung (Ubiquitous Language) giữa các lập trình viên và chuyên gia miền. Mục đích chính là giúp các nhóm phát triển hiểu sâu hơn về các vấn đề phức tạp của miền nghiệp vụ, từ đó xây dựng phần mềm chất lượng cao và dễ bảo trì hơn.

1.2. Tầm quan trọng của Domain Driven Design trong phát triển phần mềm

Trong phát triển phần mềm hiện đại, Domain-Driven Design giúp giải quyết những thách thức phức tạp thông qua việc tập trung vào mô hình hóa miền. DDD cho phép các nhóm kết nối chặt chẽ giữa lĩnh vực kinh doanh và mã nguồn, giảm thiểu sự hiểu lầm và tăng cường giao tiếp. Điều này dẫn đến việc xây dựng các hệ thống dễ mở rộng, bảo trì và thích ứng với những thay đổi yêu cầu kinh doanh.

II. Strategic Design Thiết kế Chiến lược

Strategic Design là phần cốt lõi của Domain-Driven Design tập trung vào việc định hình cấu trúc tổng thể của hệ thống. Nó giúp các nhóm xác định các Bounded Contexts (các ngữ cảnh giới hạn) và hiểu rõ mối quan hệ giữa chúng. Strategic Design bao gồm việc phân tích các Subdomains (các miền con) để xác định những phần nào là Core Domain (miền cốt lõi), Supporting Subdomain (miền hỗ trợ), và Generic Subdomain (miền chung). Thông qua Strategic Design, các tổ chức có thể phân bổ tài nguyên một cách hiệu quả, ưu tiên các phần có giá trị kinh doanh cao nhất. Việc áp dụng Strategic Design giúp tạo ra một Context Map rõ ràng, cho phép các nhóm khác nhau làm việc một cách độc lập nhưng vẫn duy trì sự tích hợp nhất quán trong toàn bộ hệ thống.

2.1. Subdomain và phân loại các loại Subdomain

Subdomain được chia thành ba loại chính dựa trên giá trị kinh doanh và độ phức tạp. Core Domain là miền cốt lõi, mang lại lợi thế cạnh tranh cho doanh nghiệp và cần được phát triển bởi những nhân viên giỏi nhất. Supporting Subdomain hỗ trợ các hoạt động kinh doanh chính nhưng không phải là yếu tố phân biệt. Generic Subdomain là những miền chung, có thể mua từ nhà cung cấp hoặc sử dụng các giải pháp sẵn có.

2.2. Bounded Context và Context Mapping

Bounded Context là một ranh giới rõ ràng trong đó một mô hình miền cụ thể có hiệu lực. Mỗi Bounded Context có ngôn ngữ chung (Ubiquitous Language) riêng và mô hình dữ liệu độc lập. Context Mapping giúp xác định mối quan hệ giữa các Bounded Contexts khác nhau thông qua các mối quan hệ như Partnership, Customer-Supplier, và Shared Kernel, đảm bảo tích hợp nhất quán.

III. Tactical Design Thiết kế Chiến thuật

Tactical Design trong Domain-Driven Design cung cấp những công cụ kỹ thuật cụ thể để xây dựng các mô hình miền (Domain Models) hiệu quả. Tactical Design bao gồm các khái niệm như Entities (các thực thể), Value Objects (các đối tượng giá trị), Aggregates (các tập hợp), Domain Events (các sự kiện miền), Repositories, Factories, và Services. Những thành phần này giúp tổ chức logic nghiệp vụ một cách rõ ràng và bảo trì. Aggregate là một nhóm các đối tượng liên quan được coi là một đơn vị duy nhất trong giao dịch, với Aggregate Root là điểm vào duy nhất. Domain Events cho phép ghi lại những thay đổi quan trọng trong miền, hỗ trợ giao tiếp không đồng bộ giữa các Bounded Contexts. Repositories cung cấp một trừu tượng hóa để truy cập dữ liệu, trong khi Factories giúp khởi tạo các đối tượng phức tạp.

3.1. Entities Value Objects và Aggregates

Entities là những đối tượng có danh tính duy nhất và có thể thay đổi theo thời gian. Value Objects không có danh tính riêng, được xác định bởi giá trị của các thuộc tính, và nên là bất biến (immutable). Aggregates là những nhóm các Entities và Value Objects liên quan, với một Aggregate Root đóng vai trò là điểm vào duy nhất. Cách tổ chức này giúp bảo vệ tính nhất quán của dữ liệu.

3.2. Domain Events Repositories và Factories

Domain Events ghi lại những sự kiện quan trọng xảy ra trong miền kinh doanh, cho phép các Bounded Contexts khác nhau giao tiếp không đồng bộ. Repositories cung cấp trừu tượng hóa để truy cập và lưu trữ Aggregates, ẩn đi chi tiết triển khai cơ sở dữ liệu. Factories giúp khởi tạo các đối tượng phức tạp một cách sạch sẽ và dễ bảo trì, đặc biệt khi quá trình khởi tạo liên quan đến logic phức tạp.

IV. Ứng dụng Thực tế Domain Driven Design trong Doanh nghiệp

Áp dụng Domain-Driven Design vào thực tế đòi hỏi sự hiểu biết sâu sắc về cấu trúc tổ chức và quy trình kinh doanh của doanh nghiệp. Ví dụ, với một doanh nghiệp bán lẻ như FPT Retail, Domain-Driven Design có thể được áp dụng để xác định các Bounded Contexts chính như Sales Domain (miền bán hàng), Inventory Domain (miền quản lý kho), Customer Domain (miền khách hàng), và Marketing Domain (miền tiếp thị). Mỗi Domain này có Ubiquitous Language riêng và mô hình dữ liệu độc lập. Bằng cách áp dụng Strategic Design, doanh nghiệp có thể xác định Core Domain (bán hàng) và ưu tiên phát triển theo đó. Tactical Design giúp xây dựng các mô hình miền cụ thể cho mỗi Bounded Context, với các Aggregates, Value Objects, và Domain Events phù hợp. Cách tiếp cận này giúp doanh nghiệp xây dựng hệ thống phần mềm linh hoạt, dễ mở rộng, và thích ứng với những thay đổi yêu cầu kinh doanh.

4.1. Phân tích Domain của FPT Retail

FPT Retail là một doanh nghiệp bán lẻ phức tạp với nhiều Domains khác nhau. Sales Domain là miền cốt lõi, mang lại lợi thế cạnh tranh trực tiếp. Inventory Domain hỗ trợ hoạt động bán hàng bằng cách quản lý kho hàng hiệu quả. Customer Domain giúp xây dựng quan hệ khách hàng lâu dài. Marketing Domain hỗ trợ quảng bá và tăng doanh số bán hàng. Việc xác định rõ ràng các Domains này giúp phân bổ tài nguyên hiệu quả.

4.2. Mô hình Bounded Contexts và quản lý Tích hợp

Trong FPT Retail, Bounded Contexts bao gồm Sales, Inventory, Customer, và Marketing. Các Contexts này cần tích hợp nhất quán thông qua các Context Maps. Sales Context cần thông tin từ Inventory về tình trạng hàng hóa và từ Customer về lịch sử mua hàng. Sử dụng Domain Events cho phép các Contexts giao tiếp không đồng bộ, giảm sự phụ thuộc và tăng tính linh hoạt của hệ thống.

Trích đoạn nội dung tài liệu

Chương 1: Giới thiệu Domain-Driven Design  Chương 2: Strategic Design  Chương 3: Tactical Design  Chương 4: Thực hành Domain-Driven Design với ví dụ thực tế SE121. Giới thiệu Domain-Driven Design 1. Lịch sử phát triển Domain-Driven Design Domain-Driven Design (DDD) là một phương pháp phát triển phần mềm được giới thiệu bởi Eric Evans trong cuốn sách Domain-Driven Design: Tackling Complexity in the Heart of Software, xuất bản vào năm 2003. DDD đã trở thành một hướng tiếp cận quan trọng để giải quyết sự phức tạp trong các hệ thống phần mềm bằng cách tập trung vào mô hình hóa và hiểu sâu về các miền (domain) của nghiệp vụ.

Dưới đây là một cái nhìn tổng quan về lịch sử phát triển của DDD:  Trước khi có DDD (1980 – 2000): o Trong các thập niên 1980 và 1990, phát triển phần mềm chủ yếu dựa trên phương pháp phân tích và thiết kế theo hướng đối tượng (Object-Oriented Analysis and Design - OOAD) cùng với các phương pháp phát triển truyền thống như Waterfall. o Trong thời kỳ này, nhiều dự án phần mềm phức tạp thường gặp khó khăn trong việc nắm bắt và mô hình hóa chính xác nhu cầu của doanh nghiệp. Các mô hình thường không phản ánh được thực tế kinh doanh hoặc không đủ linh hoạt để đáp ứng thay đổi.  Ra đời của Domain-Driven Design (2003): o Eric Evans giới thiệu khái niệm Domain-Driven Design trong cuốn sách nổi tiếng của mình.

DDD nhanh chóng trở thành một trong những phương pháp có sức ảnh hưởng nhất trong ngành phát triển phần mềm. o Triết lý của DDD xoay quanh việc mô hình hóa phần mềm dựa trên miền nghiệp vụ, sử dụng ngôn ngữ chung (Ubiquitous Language) và sự hợp tác chặt chẽ giữa các chuyên gia nghiệp vụ (domain experts) và các kỹ sư phần mềm.  Giai đoạn phát triển và ứng dụng rộng rãi (2003 - 2010): o Sau khi cuốn sách của Evans ra mắt, DDD đã thu hút được sự quan tâm và áp dụng rộng rãi trong các dự án phần mềm, đặc biệt là ở các hệ thống lớn và phức tạp. o Các công ty và chuyên gia bắt đầu chia sẻ các ví dụ và mẫu kiến trúc ứng dụng DDD.

Các mô hình như Aggregate, Entity, Value Object, Repository, và Factory dần trở nên phổ biến.  Sự phát triển của các kiến trúc và công cụ hỗ trợ (2010 - 2020): o Với sự phát triển của công nghệ và kiến trúc phần mềm như Microservices, Event-Driven Architecture, và CQRS (Command Query Responsibility Segregation), DDD đã được điều chỉnh để phù hợp hơn với các hệ thống phân tán và có quy mô lớn. o Các framework và công cụ hỗ trợ phát triển DDD như Axon Framework (dành cho Java) cũng được phát triển, giúp triển khai các khái niệm DDD dễ dàng và hiệu quả hơn.P11 - Đồ án 1  Domain-Driven Design hiện đại (2020 - Nay): o Ngày nay, DDD vẫn tiếp tục phát triển và được ứng dụng rộng rãi trong các hệ thống phức tạp. Nhiều cải tiến mới như Strategic DDD (chia hệ thống thành các Bounded Context) giúp quản lý và duy trì các hệ thống lớn một cách hiệu quả hơn.

o DDD còn được áp dụng trong các kiến trúc mới như Event Sourcing, kết hợp với các công nghệ hiện đại như Kubernetes, Docker và các giải pháp đám mây để xây dựng các hệ thống phân tán có thể mở rộng dễ dàng. Domain-Driven Design là gì? Domain-Driven Design - DDD là một phương pháp tiếp cận phát triển phần mềm tập trung vào nghiệp vụ doanh nghiệp (business domain) của ứng dụng. Trọng tâm chính của DDD là hiểu rõ và phản ánh logic nghiệp vụ phức tạp vào trong thiết kế và mã nguồn phần mềm. DDD bao gồm hai phần chính: Strategic design và Tactical design.

Strategic Design:  Thiết kế chiến lược trong DDD tập trung vào việc: o Phân tích lĩnh vực nghiệp vụ: Xác định các subdomains khác nhau, bao gồm core subdomain, supporting subdomain, và generic subdomain. o Phát triển ngôn ngữ chung (Ubiquitous Language): Tạo ra một ngôn ngữ chung, rõ ràng, nhất quán cho tất cả các bên liên quan (domain experts, software engineers, product owners, etc.) để giao tiếp về lĩnh vực nghiệp vụ. o Xác định Bounded Contexts: Phân chia hệ thống thành các ngữ cảnh bị ràng buộc, mỗi ngữ cảnh có một mô hình riêng biệt và ngôn ngữ chung riêng. o Lập Context Map: Mô tả mối quan hệ và cách thức giao tiếp giữa các ngữ cảnh bị ràng buộc.

Tatical Design:  Thiết kế chiến thuật trong DDD tập trung vào việc: o Thực hiện logic nghiệp vụ: Sử dụng các mẫu thiết kế (design patterns) như Transaction Script, Active Record, Domain Model, và Event Sourcing để triển khai logic nghiệp vụ sao cho phản ánh chính xác ngôn ngữ chung và mô hình lĩnh vực. o Tạo ra các Domain Objects: Sử dụng các khái niệm như Entity, Value object, Aggregate, Domain Event, Domain Service để mô hình hóa các khái niệm nghiệp vụ. Mục tiêu của DDD là tạo ra phần mềm phản ánh chính xác lĩnh vực nghiệp vụ, dễ dàng bảo trì, mở rộng, và thích ứng với những thay đổi trong yêu cầu nghiệp vụ.P11 - Đồ án 1 DDD đặc biệt hữu ích khi phát triển các hệ thống phần mềm phức tạp với logic nghiệp vụ phức tạp, thay đổi thường xuyên. Strategic Design là gì? Strategic Design là một phần quan trọng của Domain-Driven Design (DDD) nhằm tập trung vào cách tổ chức và kiến trúc hệ thống phần mềm ở cấp độ cao, giúp giải quyết các vấn đề phức tạp và tối ưu hóa sự phát triển của hệ thống.

Trong DDD, Strategic Design cung cấp các công cụ và mẫu thiết kế để định nghĩa và phân chia các domain thành các phần rõ ràng, độc lập, dễ quản lý, và hợp tác hiệu quả. Các khái niệm cốt lõi trong Strategic Design:  Domain  Subdomains  Domain Expert  Ubiquitous Language  Domain Modeling  Bounded Context  Integration Pattern  Context Map 2. Domain Domain, hay Business Domain xác định lĩnh vực hoạt động chính của doanh nghiệp. Nói tóm lại, nó chính là những dịch vụ mà doanh nghiệp cung cấp cho khách hàng.

Ví dụ:  Shopee cung cấp trang thương mai điện tử.  GHN được biết đến là một trong những bên cung cấp dịch vụ vận chuyển lớn ở Việt Nam.  Trung Nguyên Legend nổi tiếng về lĩnh vực cà phê. Một công ty có thể vận hành nhiều Domain.

Ví dụ, Amazon cung cấp về dịch vụ bán lẻ và dịch vụ điện toán đám mây. Grab đồng thời cung cấp dịch vụ vận tải hàng khách và giao đồ ăn. Điều quan trọng rằng một công ty cũng có thể thay đổi Domain của họ. Ví dụ như Netflix, ban đầu là một công ty cho thuê đĩa DVD qua bưu điện.

Sau đó Netflix chuyển mình sang nền tảng phát trực tuyến (Streaming) nội dung video. Subdomain Để đạt được các mục tiêu và mục đích trong Domain của mình, một công ty phải hoạt động trong nhiều Domain nhỏ hơn, hay còn gọi là Subdomain. Subdomain là một khu vực hoạt động kinh doanh chi tiết. Tất cả các Subdomain của một công ty tạo một Domain tổng quan của công ty đó.

Việc triển khai một Subdomain duy nhất là không đủ để một công ty thành công; nó chỉ là một Building Block trong hệ thống. Các Subdomain phải tương tác với nhau để đạt được các mục tiêu của công ty trong Domain của mình. Ví dụ, Starbucks có thể được biết đến nhiều nhất với cà phê của mình, nhưng để xây dựng một chuỗi cà phê thành công đòi hỏi nhiều hơn là chỉ biết cách pha cà phê ngon. Bạn cũng cần phải mua hoặc thuê bất động sản ở các địa điểm hiệu quả, thuê nhân viên và quản lý tài chính, cùng với các hoạt động khác.

Không một Subdomain nào trong số này có thể tự mình tạo ra một công ty có lợi nhuận. Tất cả các Subdomain phải tương tác với nhau là để công ty có thể cạnh tranh trong (các) Domain của mình. Sau đây là các loại subdomain.1 Core Subdomain Core Subdomain là thứ làm một công ty khác biệt so với các đối thủ. Điều này có thể là việc sáng tạo ra một sản phẩm mới hoặc tối ưu hoá quy trình để giảm chi phí vận hành.

Lấy ví dụ về Uber. Uber là một công ty cung cấp dịch vụ ridesharing. Sau khi các đối thủ cạnh tranh khác xuất hiện, Uber đã tìm cách tối ưu hoá và nâng cấp nghiệp vụ chính của mình: giảm chi phí bằng cách giúp khách hàng bắt được xe đang hướng về họ. Đây là cách mà Uber khác biệt so với các đối thủ của mình.

Chiến lược của họ là cung cấp cho dịch vụ tốt hơn cho khách hàng của họ từ đó có thể tăng được lợi nhuận. Do đó để duy trì các lợi thế cạnh tranh của mình, Core Subdomain liên quan đến việc phát minh, tối ưu hoá thông minh, bí quyết kinh doanh. Một ví dụ khác là Google Search’s ranking algorithm. Vào năm 2021, Google Ads là nền tảng chiếm phần lớn lợi nhuận của công ty.

Điều đó nói lên rằng, Google Ads không chỉ là một Subdomain mà là một Domain riêng biệt, bao gồm các Subdomain như là dịch vụ điện toán đám mây (Google Cloud Platform), các công cụ làm việc nhóm (Google Workspaces), và các lĩnh vực khác từ Alphabet, công ty mẹ của Google. Thế còn Google Search và ranking algorithm của nó thì sao? Mặc dù dịch vụ tìm kiếm không phải là một dịch vụ trả phí, tuy nhiên nó là nền tảng hiển thị lớn nhất cho Google Ads. Khả năng tìm kiếm kết quả chất lượng cao là điều thu hút lượng truy cập. Nếu cung cấp kết quả tìm kiếm không tốt do lỗi thuật toán, hoặc có một đối thủ cạnh tranh phát triển dịch vụ tìm kiếm tốt hơn, doanh thu từ quảng cáo sẽ bị ảnh hưởng.

Do đó, đối với Google, ranking algorithm là một Core Subdomain.P11 - Đồ án 1 Về độ phức tạp. Nếu một Core Subdomain dễ dàng thực hiện thì nó chỉ cung cấp lợi ích cạnh trang ngắn hạn. Do đó, như một lẽ tự nhiên thì Core Subdomain rất phức tạp. Tiếp tục với ví dụ về Uber, công ty không chỉ cung cấp một thị trường ảo cho ridersharing mà còn đột phá khỏi một kiến trúc cũ kỹ hàng thập kỷ, đó là ngành công nghiệp taxi, thông qua việc sử dụng công nghệ một các có chủ đích.

Bằng cách hiểu rõ Domain của mình, Uber đã thiết kế một phương thức vận chuyển đáng tin cậy và minh bạch hơn. Nghiệp vụ cốt lõi của công ty nên được bảo vệ để khó có thể mà tiếp cận được. Điều này sẽ làm cho các đối thủ cạnh tranh gặp khó khăn trong việc cố gắng sao chép hoặc bắt chước. Điều quan trọng nữa là Core Subdomain không nhất thiết phải là công nghệ.

Không phải tất cả các vấn đề của doanh nghiệp đều được giải quyết thông qua thuật toán hay là các giải pháp công nghệ khác.