Clean Architecture là gì? Cấu trúc và quy trình triển khai

Khi một dự án phát triển về quy mô, quản lý business logic, database, framework và các dịch vụ bên ngoài trong cùng một cấu trúc có thể khiến mã nguồn ngày càng khó bảo trì. Clean Architecture được xây dựng nhằm giải quyết vấn đề này bằng cách phân tách hệ thống thành các tầng có trách nhiệm rõ ràng, đồng thời kiểm soát hướng phụ thuộc giữa các thành phần. Mô hình này giúp business logic ít bị chi phối bởi công nghệ bên ngoài và thuận lợi hơn cho kiểm thử, mở rộng, thay đổi. Vậy Clean Architecture là gì, cấu trúc gồm những tầng nào và triển khai như thế nào trong một dự án thực tế? Bài viết dưới đây sẽ giúp bạn hiểu rõ nguyên tắc, ưu nhược điểm, trường hợp nên áp dụng và những lỗi thường gặp khi xây dựng hệ thống theo Clean Architecture.

 

 

Clean Architecture là gì?

Clean Architecture là mô hình kiến trúc phần mềm do Robert C. Martin (Uncle Bob) đề xuất, nhằm tổ chức mã nguồn thành các lớp có trách nhiệm rõ ràng và hạn chế sự phụ thuộc giữa các thành phần. Mô hình này đặt logic nghiệp vụ ở trung tâm, tách biệt với giao diện người dùng, cơ sở dữ liệu, framework và các hệ thống bên ngoài.

Clean Architecture hoạt động dựa trên Dependency Rule, trong đó các lớp bên ngoài có thể phụ thuộc vào lớp bên trong nhưng lớp bên trong không phụ thuộc trực tiếp vào các chi tiết triển khai bên ngoài. Nhờ đó, hệ thống dễ kiểm thử, bảo trì, mở rộng và thay đổi công nghệ mà ít ảnh hưởng đến logic cốt lõi.

 

 

Cấu trúc 4 tầng trong Clean Architecture

Clean Architecture thường được tổ chức thành 4 tầng chính, mỗi tầng đảm nhận một vai trò riêng trong hệ thống. Các tầng được sắp xếp theo mức độ phụ thuộc, trong đó những thành phần chứa logic cốt lõi nằm ở bên trong và ít phụ thuộc vào công nghệ bên ngoài. Cấu trúc này giúp mã nguồn dễ kiểm thử, thay đổi và mở rộng khi yêu cầu của phần mềm phát triển.

1. Entities - Lớp thực thể

Entities là lớp đại diện cho các đối tượng và quy tắc nghiệp vụ cốt lõi của hệ thống. Những đối tượng này có thể là User, Product, Order, Account hoặc các thực thể khác tùy thuộc vào lĩnh vực mà phần mềm phục vụ. Đây là lớp có tính ổn định cao và ít bị ảnh hưởng khi các yêu cầu về giao diện hoặc công nghệ triển khai thay đổi.

Lớp Entities không phụ thuộc trực tiếp vào framework, cơ sở dữ liệu, giao diện người dùng hay các dịch vụ bên ngoài. Thay vào đó, lớp này tập trung mô tả dữ liệu, trạng thái và các hành vi liên quan đến đối tượng nghiệp vụ. Chẳng hạn, Entity Order có thể chứa quy tắc kiểm tra trạng thái đơn hàng hoặc tính tổng giá trị đơn.

Nhờ được tách biệt khỏi các chi tiết triển khai, Entities có thể được tái sử dụng ở nhiều Use Cases khác nhau trong hệ thống. Đây cũng là lớp nằm gần trung tâm của Clean Architecture, giúp bảo vệ logic nghiệp vụ quan trọng trước những thay đổi từ các tầng bên ngoài.

2. Use Cases - Lớp nghiệp vụ ứng dụng

Use Cases là lớp chịu trách nhiệm điều phối các quy trình nghiệp vụ cụ thể mà hệ thống cần thực hiện. Mỗi Use Case thường tương ứng với một chức năng hoặc mục tiêu nhất định, chẳng hạn đăng ký tài khoản, tạo đơn hàng, xử lý thanh toán hoặc cập nhật thông tin. Lớp này sử dụng các Entities và các quy tắc để xử lý yêu cầu theo đúng nghiệp vụ.

Use Cases tập trung vào hệ thống cần làm gì thay vì cách chức năng được hiển thị hoặc triển khai. Lớp này không phụ thuộc trực tiếp vào giao diện người dùng, framework hay cơ sở dữ liệu mà thường giao tiếp với các thành phần bên ngoài thông qua interface hoặc abstraction. Nhờ đó, logic nghiệp vụ có thể được kiểm thử độc lập và ít bị ảnh hưởng khi thay đổi công nghệ ở các tầng bên ngoài.

3. Interface Adapters - Lớp chuyển đổi giao diện

Interface Adapters đóng vai trò là lớp trung gian chuyển đổi dữ liệu giữa các thành phần bên ngoài hệ thống và logic nghiệp vụ cốt lõi bên trong. Lớp này chịu trách nhiệm chuyển đổi dữ liệu từ định dạng phù hợp với các thành phần bên ngoài, chẳng hạn JSON từ HTTP Request hoặc dữ liệu từ giao diện người dùng, sang cấu trúc dữ liệu mà Use Cases và Entities có thể xử lý.

Các thành phần phổ biến trong tầng Interface Adapters gồm:

- Controllers: Tiếp nhận yêu cầu từ người dùng hoặc hệ thống bên ngoài, chuyển đổi dữ liệu đầu vào thành Input Data và gọi Use Case tương ứng để xử lý.

- Presenters/ ViewModels: Tiếp nhận Output Data từ Use Case, sau đó chuyển đổi và định dạng dữ liệu theo cấu trúc phù hợp với giao diện người dùng hoặc hệ thống nhận kết quả.

- Gateway/ Repository Implementations: Hiện thực các interface được định nghĩa bởi tầng Use Cases, đảm nhiệm việc kết nối với cơ sở dữ liệu, dịch vụ bên thứ ba, hệ thống lưu trữ hoặc bộ nhớ đệm (cache).

Nhờ có Interface Adapters, các thành phần cốt lõi như Entities và Use Cases không cần phụ thuộc trực tiếp vào cách dữ liệu được hiển thị hoặc lưu trữ. Logic nghiệp vụ có thể hoạt động độc lập với giao diện web, mobile hay terminal, đồng thời không cần biết dữ liệu phía dưới được lưu trữ bằng SQL, NoSQL hay một cơ chế khác. Những khác biệt về định dạng và cách thức giao tiếp giữa hệ thống bên trong và bên ngoài được xử lý tại tầng Interface Adapters, qua đó giúp kiến trúc hệ thống tách biệt trách nhiệm, giảm phụ thuộc và dễ thay đổi hơn.

4. Frameworks & Drivers - Lớp bên ngoài

Frameworks & Drivers là tầng ngoài cùng của Clean Architecture, nơi tập trung các công nghệ và thành phần cụ thể dùng để triển khai, kết nối và vận hành hệ thống. Tầng này chứa những yếu tố có tính phụ thuộc cao như framework, cơ sở dữ liệu, giao diện người dùng, thiết bị, hệ điều hành hoặc các thư viện bên thứ ba.

Các thành phần phổ biến trong tầng Frameworks & Drivers gồm:

- Web Frameworks: Cung cấp nền tảng để xây dựng và vận hành ứng dụng web, chẳng hạn Express, Laravel, Django hoặc Spring.

- Database: Đảm nhiệm việc lưu trữ và truy xuất dữ liệu thông qua các hệ quản trị cơ sở dữ liệu như MySQL, PostgreSQL. Thành phần này cung cấp dữ liệu cho các tầng bên trong khi hệ thống cần đọc, ghi, cập nhật thông tin.

- UI/ External Interfaces: Bao gồm giao diện web, mobile, terminal hoặc các hệ thống bên ngoài mà người dùng và ứng dụng khác tương tác trực tiếp.

- External Services & Tools: Các dịch vụ, thư viện hoặc công cụ bên thứ ba được tích hợp để bổ sung chức năng cho hệ thống. Lớp này có thể bao gồm API, cơ sở dữ liệu, dịch vụ thanh toán hoặc các nền tảng bên ngoài cần sử dụng.

Điểm quan trọng của tầng này là công nghệ bên ngoài không được phép chi phối logic nghiệp vụ cốt lõi. Frameworks & Drivers chỉ cung cấp cơ chế để hệ thống giao tiếp với thế giới bên ngoài, trong khi các quy tắc nghiệp vụ vẫn được duy trì độc lập ở những tầng bên trong. Nhờ đó, hệ thống có thể thay đổi framework, cơ sở dữ liệu hoặc công nghệ giao diện với ít ảnh hưởng hơn đến Entities và Use Cases.

 

 

5 tính chất độc lập làm nên giá trị của Clean Architecture

Clean Architecture được xây dựng dựa trên nguyên tắc tách biệt logic nghiệp vụ cốt lõi khỏi các thành phần bên ngoài. Nhờ đó, hệ thống không bị ràng buộc quá chặt vào công nghệ, giao diện hay cách thức lưu trữ dữ liệu cụ thể. Dưới đây là 5 tính chất độc lập giúp kiến trúc trở nên linh hoạt, dễ bảo trì và thuận tiện mở rộng trong quá trình phát triển.

1. Độc lập với framework

Hệ thống không bị phụ thuộc hoặc bị ràng buộc bởi sự tồn tại hay cơ chế hoạt động của bất kỳ thư viện hay framework nào. Thay vì thiết kế toàn bộ kiến trúc xoay quanh các tính năng có sẵn của một web framework cụ thể (như Spring, ASP.NET, NestJS hay Django), Clean Architecture coi framework đơn thuần là các công cụ hỗ trợ ngoại vi. Điều này có nghĩa là bạn sử dụng framework theo cách bạn muốn chứ không để triết lý của framework ép buộc cách bạn tổ chức logic nghiệp vụ. Khi một công nghệ trở nên lỗi thời, bị ngừng hỗ trợ hoặc hệ thống cần nâng cấp lên một phiên bản framework mới, bạn hoàn toàn có thể thay thế hoặc chuyển đổi mà không phải đập đi xây lại toàn bộ nghiệp vụ cốt lõi.

2. Độc lập với giao diện người dùng

Clean Architecture tách biệt logic nghiệp vụ khỏi cách thức hệ thống tương tác với người dùng. Các Use Cases không cần biết dữ liệu được nhập từ website, mobile, desktop hay terminal mà chỉ tiếp nhận dữ liệu đầu vào theo cấu trúc đã được quy định và thực hiện các quy tắc nghiệp vụ tương ứng. Phần giao tiếp với người dùng được xử lý bởi các thành phần như Controllers, Presenters hoặc ViewModels, giúp chuyển đổi dữ liệu giữa giao diện và logic bên trong.

Nhờ sự phân tách này, thay đổi giao diện không làm ảnh hưởng trực tiếp đến các chức năng cốt lõi của hệ thống. Chẳng hạn, một nghiệp vụ đang được sử dụng trên website có thể được triển khai thêm trên mobile mà không cần viết lại toàn bộ logic xử lý. Điều này giúp hệ thống dễ mở rộng sang nhiều nền tảng, đồng thời giảm chi phí bảo trì khi yêu cầu về giao diện thay đổi.

3. Độc lập với database

Mô hình Clean Architecture tách biệt logic nghiệp vụ khỏi cơ chế lưu trữ dữ liệu cụ thể. Các Entities và Use Cases không truy cập trực tiếp vào MySQL, PostgreSQL, MongoDB hay một hệ quản trị cơ sở dữ liệu cụ thể nào. Thay vào đó, tầng nghiệp vụ chỉ làm việc với các interface như Repository hoặc Gateway, trong khi phần triển khai kết nối và truy xuất dữ liệu được đặt ở các tầng bên ngoài.

Cách tổ chức này giúp hệ thống dễ dàng thay đổi công nghệ lưu trữ mà không làm ảnh hưởng đáng kể đến logic nghiệp vụ. Chẳng hạn, khi cần chuyển từ MySQL sang PostgreSQL hoặc thay đổi cách lưu trữ dữ liệu, developer chủ yếu cần điều chỉnh phần Repository Implementation thay vì viết lại các Use Cases. Nhờ đó, hệ thống giảm sự phụ thuộc vào database, đồng thời linh hoạt hơn khi mở rộng hoặc thay đổi yêu cầu kỹ thuật

4. Độc lập với các dịch vụ bên ngoài

Clean architecture project structure giúp logic nghiệp vụ không bị phụ thuộc trực tiếp vào các dịch vụ hoặc hệ thống bên thứ ba như cổng thanh toán, dịch vụ gửi email, API của đối tác, dịch vụ lưu trữ đám mây hay hệ thống xác thực. Thay vì gọi trực tiếp các dịch vụ này, Use Cases chỉ tương tác với các interface mô tả những chức năng mà hệ thống cần. Phần kết nối và triển khai cụ thể được đặt ở các tầng bên ngoài thông qua các Gateway hoặc thành phần tích hợp tương ứng.

Nhờ đó, khi một dịch vụ bên ngoài thay đổi API, chính sách hoặc cần được thay thế bằng nhà cung cấp khác, phần logic nghiệp vụ bên trong vẫn có thể được giữ nguyên. Developer chỉ cần điều chỉnh lớp triển khai kết nối với dịch vụ đó mà không phải thay đổi toàn bộ Use Cases. Cách tiếp cận này giúp giảm mức độ phụ thuộc vào bên thứ ba, hạn chế tác động dây chuyền và tăng khả năng thích ứng của hệ thống khi môi trường bên ngoài thay đổi.

5. Dễ dàng kiểm thử độc lập

Clean Architecture giúp logic nghiệp vụ có thể được kiểm thử độc lập mà không cần phụ thuộc vào framework, giao diện người dùng, database hoặc các dịch vụ bên ngoài. Do Entities và Use Cases được tách khỏi các thành phần triển khai cụ thể, developer có thể kiểm tra từng quy tắc và luồng nghiệp vụ bằng dữ liệu đầu vào giả lập mà không cần khởi chạy toàn bộ hệ thống.

Khi kiểm thử các thành phần phụ thuộc bên ngoài, developer có thể sử dụng Mock, Stub hoặc các đối tượng giả lập để thay thế database, API và dịch vụ liên quan. Cách tiếp cận này giúp bài kiểm thử chạy nhanh, dễ kiểm soát và tập trung chính xác vào hành vi cần xác minh. Đồng thời, khi phát hiện lỗi, developer cũng dễ xác định lỗi nằm ở logic nghiệp vụ hay ở lớp tích hợp bên ngoài, từ đó giảm thời gian sửa lỗi và bảo trì hệ thống.

 

 

So sánh Clean Architecture với các mô hình kiến trúc khác

Mỗi mô hình kiến trúc phần mềm có cách tổ chức thành phần và mức độ phân tách trách nhiệm khác nhau. Clean Architecture tập trung mạnh vào việc bảo vệ logic nghiệp vụ khỏi sự phụ thuộc vào framework, giao diện, database và các dịch vụ bên ngoài. Bảng dưới đây giúp phân biệt Clean Architecture với một số mô hình phổ biến như Layered Architecture, MVC và Hexagonal Architecture.
 

 

Clean Architecture thường được sử dụng trong những trường hợp nào?

Clean Architecture không nhất thiết phù hợp với mọi dự án, đặc biệt khi hệ thống có quy mô nhỏ và logic nghiệp vụ đơn giản. Mô hình này phát huy giá trị rõ rệt ở những dự án có yêu cầu cao về khả năng mở rộng, bảo trì, kiểm thử và hạn chế phụ thuộc vào công nghệ bên ngoài. Một số trường hợp tiêu biểu gồm:

- Dự án web có business logic phức tạp: Clean Architecture phù hợp với các dự án web có business logic phức tạp, bao gồm nhiều quy tắc nghiệp vụ, điều kiện xử lý hoặc luồng tương tác giữa các chức năng. Với các dự án clean architecture PHP, tách Entities, Use Cases và các tầng bên ngoài giúp logic nghiệp vụ được tổ chức rõ ràng, hạn chế tình trạng xử lý bị phân tán trong Controller hoặc phụ thuộc trực tiếp vào framework. Điều này đặc biệt hữu ích với các hệ thống như thương mại điện tử, quản lý doanh nghiệp, tài chính hoặc các nền tảng có quy trình nghiệp vụ nhiều bước.

- Hệ thống dự kiến phát triển và mở rộng lâu dài: Với những hệ thống được định hướng phát triển trong nhiều năm, yêu cầu và công nghệ có thể thay đổi liên tục theo thời gian. Clean Architecture giúp tách logic nghiệp vụ khỏi các thành phần dễ thay đổi như framework, database hoặc giao diện, từ đó giảm tác động khi hệ thống được mở rộng. Developer có thể bổ sung tính năng hoặc thay đổi một thành phần cụ thể mà không phải chỉnh sửa quá nhiều phần mã nguồn.

- Hệ thống đa nền tảng dùng chung core logic: Clean Architecture cũng phù hợp với các hệ thống cần triển khai trên nhiều nền tảng nhưng vẫn muốn sử dụng chung logic nghiệp vụ. Chẳng hạn, một hệ thống có thể cung cấp website, ứng dụng mobile và API nhưng cùng sử dụng một tập Use Cases và Entities ở phần core. Tách giao diện khỏi nghiệp vụ giúp mỗi nền tảng có thể phát triển cách tương tác riêng mà không cần sao chép hoặc viết lại toàn bộ logic xử lý.

- Dự án yêu cầu độ tin cậy cao & kiểm thử tự động khắt khe: Đối với những hệ thống yêu cầu độ tin cậy cao, khả năng kiểm thử độc lập là một trong những lợi thế quan trọng của Clean Architecture. Logic nghiệp vụ có thể được kiểm thử mà không cần phụ thuộc trực tiếp vào database, framework hoặc các dịch vụ bên ngoài. Developer có thể xây dựng unit test và sử dụng Mock hoặc Stub để kiểm tra từng quy tắc nghiệp vụ, giúp phát hiện lỗi sớm và giảm rủi ro khi thay đổi mã nguồn. 

- Dự án có nguy cơ cao phải thay đổi công nghệ hoặc dịch vụ bên thứ ba: Clean architecture project structure đặc biệt hữu ích khi dự án có khả năng phải thay đổi framework, database, API hoặc dịch vụ bên thứ ba trong tương lai. Các thành phần bên ngoài được cô lập thông qua interface và adapter, vì vậy thay thế một công nghệ thường chỉ tác động đến phần triển khai tương ứng. Ví dụ, hệ thống có thể chuyển đổi nhà cung cấp dịch vụ thanh toán hoặc thay đổi database mà không cần viết lại toàn bộ logic nghiệp vụ cốt lõi. 

Trường hợp không cần áp dụng Clean Architecture

Clean Architecture mang lại nhiều lợi ích về khả năng mở rộng và bảo trì, nhưng không phải dự án nào cũng cần áp dụng đầy đủ mô hình này. Với những hệ thống nhỏ, vòng đời ngắn hoặc nghiệp vụ đơn giản, xây dựng nhiều tầng và abstraction có thể làm tăng độ phức tạp không cần thiết. Một số trường hợp có thể cân nhắc sử dụng kiến trúc đơn giản hơn bao gồm:

- Dự án nhỏ, nghiệp vụ đơn giản: Nếu dự án chỉ có một số chức năng cơ bản và ít quy tắc nghiệp vụ, phân chia thành nhiều tầng như Entities, Use Cases, Interface Adapters và Frameworks & Drivers có thể tạo thêm mã nguồn và cấu trúc phải quản lý. Đặc biệt với các dự án clean architecture PHP quy mô nhỏ, việc xây dựng đầy đủ các tầng và abstraction có thể không mang lại nhiều giá trị nếu business logic đơn giản. Trong trường hợp này, một kiến trúc đơn giản hơn có thể đáp ứng tốt nhu cầu mà không cần xây dựng đầy đủ clean architecture project structure. 

- Prototype hoặc MVP cần triển khai nhanh: Với sản phẩm đang ở giai đoạn thử nghiệm, mục tiêu thường là nhanh chóng xây dựng phiên bản đầu tiên để kiểm chứng ý tưởng và thu thập phản hồi. Đầu tư quá nhiều thời gian vào abstraction, interface và phân tách dependency có thể làm chậm quá trình phát triển. Khi sản phẩm đã xác định rõ hướng đi, đội ngũ có thể từng bước tái cấu trúc nếu cần.

- Dự án có vòng đời ngắn: Những ứng dụng được xây dựng để phục vụ một nhu cầu nhất thời hoặc dự kiến không tiếp tục phát triển lâu dài thường không cần mức độ tách biệt cao của Clean Architecture. Chi phí xây dựng và duy trì các tầng trong clean architecture PHP có thể lớn hơn lợi ích mà chúng mang lại trong suốt vòng đời dự án.

- Đội ngũ nhỏ và chưa có kinh nghiệm với kiến trúc phức tạp: Clean Architecture yêu cầu developer hiểu rõ về dependency, abstraction, interface và trách nhiệm của từng tầng. Nếu áp dụng máy móc, hệ thống có thể xuất hiện nhiều lớp trung gian nhưng không tạo ra giá trị thực tế. Trong trường hợp này, lựa chọn kiến trúc phù hợp với quy mô dự án và năng lực đội ngũ sẽ hiệu quả hơn. 
 

 

Quy trình 5 bước triển khai Clean Architecture cho dự án web thực tế

Triển khai Clean Architecture nên được thực hiện theo từng bước, bắt đầu từ logic nghiệp vụ cốt lõi rồi mới mở rộng ra các thành phần giao tiếp và công nghệ bên ngoài. Cách tiếp cận này giúp developer xác định rõ trách nhiệm của từng tầng, kiểm soát hướng phụ thuộc và hạn chế việc logic nghiệp vụ bị gắn chặt với framework hoặc database. Quy trình dưới đây có thể áp dụng cho nhiều dự án web, đặc biệt với những hệ thống có yêu cầu mở rộng và bảo trì lâu dài.

Bước 1: Khởi tạo Domain Entities

Ở bước đầu tiên, developer xác định các đối tượng nghiệp vụ cốt lõi và xây dựng chúng trong tầng Domain. Đây là nền tảng của hệ thống nên cần tập trung vào nghiệp vụ, không đưa các chi tiết liên quan đến framework, database hoặc giao diện vào Entity.

Có thể thực hiện theo các bước:

- Xác định các đối tượng nghiệp vụ chính: Đọc yêu cầu dự án và liệt kê những đối tượng có vai trò quan trọng trong nghiệp vụ, chẳng hạn User, Product, Order, Payment trong một hệ thống thương mại điện tử.

- Xác định thuộc tính của từng Entity: Xác định những dữ liệu cần thiết để mô tả trạng thái của đối tượng. Ví dụ, Product có thể gồm id, name, price, quantity và status.

- Xác định business rules: Đưa những quy tắc nghiệp vụ thuộc về Entity vào bên trong Entity. Chẳng hạn, Order không thể chuyển sang trạng thái thanh toán nếu đơn hàng không hợp lệ hoặc đã bị hủy.

- Xây dựng class cho từng Entity: Chuyển các đối tượng nghiệp vụ thành các class độc lập với framework và database. Các class này chỉ tập trung thể hiện dữ liệu và hành vi nghiệp vụ, không trực tiếp xử lý HTTP Request, truy vấn database hay hiển thị giao diện.

- Kiểm tra tính độc lập của Domain: Đảm bảo Entity có thể hoạt động và được kiểm thử mà không cần khởi chạy framework, kết nối database hoặc phụ thuộc vào các dịch vụ bên ngoài.

Ví dụ với website bán hàng, developer có thể bắt đầu bằng việc xác định Product là một Domain Entity, sau đó mô tả các thuộc tính như tên, giá và số lượng, đồng thời đưa những quy tắc như giá không được âm hoặc số lượng tồn kho không được nhỏ hơn 0 vào logic của Entity.

Bước 2: Xây dựng Use Cases & khai báo Ports

Sau khi xác định Domain Entities, bước tiếp theo là xây dựng Use Cases để mô tả các nghiệp vụ mà hệ thống cần thực hiện. Đồng thời, developer khai báo Ports dưới dạng các interface để xác định cách Use Cases giao tiếp với những thành phần bên ngoài mà không tạo ra dependency trực tiếp.

Có thể triển khai theo các bước:

- Liệt kê các nghiệp vụ chính: Xác định những hành động mà hệ thống cần thực hiện, chẳng hạn CreateOrder, GetProduct, ProcessPayment hoặc CancelOrder. Mỗi nghiệp vụ quan trọng có thể được tổ chức thành một Use Case.

- Xác định Input và Output: Quy định dữ liệu mà Use Case cần nhận vào và kết quả cần trả về. Việc này giúp tách quá trình xử lý nghiệp vụ khỏi cách dữ liệu được truyền từ HTTP Request, giao diện hay các nguồn khác.

- Triển khai logic nghiệp vụ: Use Case điều phối Entities và thực hiện các quy tắc cần thiết để hoàn thành một nghiệp vụ cụ thể. Phần này không nên trực tiếp xử lý HTTP, truy vấn database hoặc gọi API của bên thứ ba.

- Xác định các dependency cần thiết: Xác định Use Case cần những thành phần bên ngoài nào để hoàn thành nghiệp vụ, chẳng hạn Repository để lấy dữ liệu, Payment Gateway để xử lý thanh toán hoặc Email Service để gửi thông báo.

- Khai báo Ports: Tạo các interface mô tả những chức năng mà Use Case cần từ bên ngoài. Ví dụ, OrderRepository có thể định nghĩa các phương thức như findById() hoặc save(), nhưng không quy định cách dữ liệu thực sự được lưu trữ.

- Giữ dependency hướng vào bên trong: Use Cases chỉ phụ thuộc vào các Ports/Interfaces, không phụ thuộc trực tiếp vào MySQL, Stripe, Laravel hay bất kỳ công nghệ triển khai cụ thể nào. Các thành phần bên ngoài sẽ hiện thực những interface này ở các bước tiếp theo.

Bước 3: Triển khai tầng Adapters

Sau khi hoàn thiện Domain và Use Cases, bước tiếp theo là xây dựng tầng Adapters để kết nối logic nghiệp vụ với các thành phần bên ngoài. Tầng này thường bao gồm Controllers, Presenters, Repository Adapters và các thành phần có nhiệm vụ chuyển đổi dữ liệu giữa hệ thống và các interface bên ngoài. Controller tiếp nhận request, chuyển dữ liệu thành Input phù hợp rồi gọi Use Case, trong khi Presenter xử lý Output từ Use Case thành response mà API hoặc giao diện có thể sử dụng. Các thành phần Adapter cần tập trung vào việc chuyển đổi dữ liệu và giao tiếp với hệ thống bên ngoài, không nên chứa business logic cốt lõi. 

Bước 4: Cài đặt hạ tầng & repositories thực tế

Sau khi xác định các interface và quy tắc nghiệp vụ ở những tầng bên trong, developer tiến hành xây dựng các thành phần kỹ thuật cụ thể ở Infrastructure Layer. Đây là bước kết nối logic của hệ thống với database, framework, API và các dịch vụ bên ngoài.

Có thể triển khai theo các công việc sau:

- Cài đặt repository thực tế: Xây dựng các class như UserRepositoryImpl, ProductRepositoryImpl để hiện thực các interface repository đã được định nghĩa ở tầng bên trong.

- Kết nối cơ sở dữ liệu: Cấu hình MySQL, PostgreSQL hoặc hệ quản trị cơ sở dữ liệu phù hợp để thực hiện các thao tác thêm, sửa, xóa và truy vấn dữ liệu.

- Tích hợp ORM hoặc thư viện truy cập dữ liệu: Sử dụng các công cụ như Entity Framework, Hibernate, Prisma hoặc TypeORM để giảm mã lặp và hỗ trợ làm việc với database.

- Kết nối dịch vụ bên ngoài: Triển khai các thành phần giao tiếp với API thanh toán, dịch vụ gửi email, lưu trữ file hoặc các nền tảng bên thứ ba mà hệ thống cần sử dụng.

- Cấu hình framework và hạ tầng: Thiết lập các thành phần liên quan đến server, database connection, authentication, logging, caching và các cấu hình môi trường.

- Ánh xạ dữ liệu: Chuyển đổi dữ liệu giữa database model, entity và các đối tượng mà Use Case sử dụng. Việc này giúp cấu trúc dữ liệu bên ngoài không làm thay đổi trực tiếp Business Rules.

- Đảm bảo Dependency Rule: Các thành phần Infrastructure được phép phụ thuộc vào những interface nằm ở tầng bên trong, thay vì khiến Business Rules phụ thuộc ngược vào database hoặc framework.

Bước 5: Kết nối các tầng bằng Dependency Injection

Sau khi hoàn thiện các thành phần ở từng tầng, developer cần kết nối chúng để hệ thống có thể phối hợp và xử lý request. Dependency Injection (DI) được sử dụng để cung cấp các dependency cho class thay vì để class tự khởi tạo chúng. Cách này giúp các tầng giao tiếp với nhau thông qua interface và duy trì nguyên tắc Dependency Rule của Clean Architecture.

Có thể triển khai theo các công việc sau:

- Xác định dependency cần inject: Xác định những thành phần mà một class cần sử dụng, chẳng hạn Use Case cần UserRepository để truy xuất dữ liệu.

- Inject thông qua interface: Use Case chỉ nhận UserRepository thay vì phụ thuộc trực tiếp vào UserRepositoryImpl. Nhờ đó, tầng nghiệp vụ không cần biết repository được triển khai bằng công nghệ nào.

- Đăng ký implementation: Cấu hình Dependency Injection Container để ánh xạ interface với implementation tương ứng, chẳng hạn UserRepository → UserRepositoryImpl.

- Kết nối Use Case với Controller: Controller nhận request từ bên ngoài, sau đó gọi Use Case đã được DI cung cấp đầy đủ dependency để thực hiện nghiệp vụ.

- Cấu hình dependency ở Composition Root: Các dependency thường được khởi tạo và kết nối tại một vị trí tập trung như Program, Startup, main hoặc module cấu hình của ứng dụng. Đây là nơi quyết định hệ thống sử dụng implementation cụ thể nào.

- Hạn chế khởi tạo dependency trực tiếp: Không nên để Use Case tự tạo new UserRepositoryImpl() hoặc tự khởi tạo database connection. Điều này tạo coupling với Infrastructure và làm giảm khả năng thay thế, kiểm thử các thành phần.

Clean Architecture có thể áp dụng với những công nghệ nào?

Bản chất của Clean Architecture là một tập hợp các nguyên tắc và tư duy thiết kế phần mềm, không phải một công cụ hay framework cụ thể. Vì vậy, kiến trúc này có tính linh hoạt cao và có thể được triển khai trên nhiều ngôn ngữ lập trình, nền tảng và mô hình hệ thống khác nhau. Điều kiện quan trọng là công nghệ được lựa chọn phải cho phép tổ chức các thành phần theo hướng tách biệt trách nhiệm, trừu tượng hóa dependency và kiểm soát hướng phụ thuộc.

- Ngôn ngữ hướng đối tượng (OOP): Clean Architecture đặc biệt phù hợp với các ngôn ngữ như Java (Spring Boot), C# (.NET) và **Kotlin). Hệ thống kiểu dữ liệu chặt chẽ cùng cơ chế Interface và Dependency Injection (DI) giúp developer dễ dàng xác định ranh giới giữa các tầng, tách logic nghiệp vụ khỏi thành phần bên ngoài và thực hiện nguyên tắc Dependency Inversion.

- JavaScript và TypeScript: Clean Architecture được áp dụng phổ biến trong các ứng dụng backend xây dựng trên Node.js, đặc biệt với NestJS. Cơ chế module, dependency injection và IoC của NestJS tạo điều kiện thuận lợi để tổ chức các thành phần theo hướng tách biệt giữa Domain, Application và Infrastructure. Cách tiếp cận này cũng có thể áp dụng cho các dự án TypeScript full-stack có quy mô và business logic phức tạp.

- Ngôn ngữ hiệu năng cao: Go và Rust cũng có thể triển khai Clean Architecture thông qua các cơ chế interface, composition và module hóa. Việc phân tách business logic khỏi database, HTTP framework hoặc các dịch vụ bên ngoài giúp hệ thống dễ kiểm thử và thay thế thành phần, đồng thời vẫn duy trì đặc tính hiệu năng của ngôn ngữ.

- Phát triển ứng dụng mobile: Clean Architecture được sử dụng trong phát triển ứng dụng Android với Kotlin và iOS với Swift, cũng như các nền tảng đa nền tảng như Flutter và Dart. Kiến trúc này giúp tách logic nghiệp vụ và xử lý dữ liệu khỏi lớp giao diện, từ đó hạn chế việc business logic bị gắn chặt với vòng đời hoặc thành phần UI.

- Web frontend quy mô lớn: Với các dự án sử dụng React, Vue hoặc Angular, một số nguyên tắc của Clean Architecture có thể được áp dụng để tách business logic khỏi component giao diện. Các chức năng xử lý dữ liệu, state hoặc nghiệp vụ có thể được tổ chức thành những module độc lập, giúp tăng khả năng tái sử dụng và giảm sự phụ thuộc trực tiếp vào thư viện UI.

- Monolith và Microservices: Clean Architecture có thể được áp dụng cho cả Modular Monolith và Microservices. Trong Modular Monolith, từng module có thể được tổ chức với ranh giới nghiệp vụ và dependency rõ ràng. Với Microservices, mỗi service có thể áp dụng các nguyên tắc của Clean Architecture để cô lập business logic khỏi database, API framework và các dịch vụ hạ tầng, qua đó tăng tính độc lập và khả năng bảo trì.

 

 

Đánh giá lợi ích và hạn chế khi áp dụng Clean Architecture 

Clean Architecture mang lại nhiều lợi ích trong việc tổ chức và phát triển hệ thống, đặc biệt với những dự án có business logic phức tạp và vòng đời dài. Tuy nhiên, mô hình này cũng yêu cầu nhiều công sức hơn trong quá trình thiết kế và triển khai. Vì vậy, cần đánh giá cả ưu điểm và hạn chế để lựa chọn cách áp dụng phù hợp với quy mô, mục tiêu và nguồn lực của từng dự án. 

1. Lợi ích khi áp dụng mô hình Clean Architecture

Clean Architecture tập trung vào việc bảo vệ logic nghiệp vụ cốt lõi khỏi sự phụ thuộc vào các thành phần bên ngoài. Khi được triển khai đúng cách, mô hình này có thể mang lại những lợi ích đáng kể trong quá trình phát triển, kiểm thử và bảo trì hệ thống: 

- Giảm sự phụ thuộc vào công nghệ: Logic nghiệp vụ không bị gắn chặt với framework, database, giao diện hoặc dịch vụ bên thứ ba. Nhờ đó, hệ thống có thể thay đổi công nghệ ở tầng ngoài mà ít ảnh hưởng đến phần xử lý nghiệp vụ cốt lõi.

- Tăng khả năng kiểm thử: Entities và Use Cases có thể được kiểm thử độc lập với database, framework hoặc API bên ngoài. Developer có thể sử dụng Mock và Stub để mô phỏng dependency, từ đó xây dựng các bài kiểm thử nhanh và dễ kiểm soát hơn.

- Tái sử dụng logic nghiệp vụ: Khi business logic được tách khỏi giao diện và các công nghệ triển khai, cùng một Use Case có thể được sử dụng bởi nhiều giao diện hoặc nền tảng khác nhau. Điều này đặc biệt hữu ích với hệ thống cung cấp đồng thời web, mobile và API.

- Dễ thay thế thành phần bên ngoài: Database, framework hoặc dịch vụ bên thứ ba có thể được thay thế thông qua các interface và adapter mà không nhất thiết phải viết lại logic nghiệp vụ. Khả năng này giúp hệ thống thích ứng tốt hơn khi yêu cầu kỹ thuật hoặc môi trường triển khai thay đổi.

- Cải thiện khả năng cộng tác trong đội ngũ: Các tầng có trách nhiệm tương đối rõ ràng giúp developer dễ hiểu cấu trúc hệ thống và xác định phạm vi công việc. Khi dự án có nhiều thành viên hoặc nhiều nhóm cùng phát triển, việc phân chia ranh giới giữa các thành phần có thể giúp giảm xung đột và hạn chế tác động chéo.

2. Hạn chế của Clean Architecture

Bên cạnh những lợi ích về tính độc lập và khả năng bảo trì, Clean Architecture cũng có một số hạn chế cần cân nhắc trước khi áp dụng. Mô hình này đòi hỏi developer đầu tư nhiều hơn vào việc thiết kế cấu trúc và quản lý dependency, vì vậy có thể không phù hợp với mọi loại dự án.

- Cấu trúc phức tạp hơn: Clean Architecture thường yêu cầu nhiều tầng, interface, adapter và abstraction. Với những dự án nhỏ, cấu trúc này có thể tạo ra nhiều lớp trung gian không thực sự cần thiết.

- Tăng thời gian phát triển ban đầu: Developer cần dành thời gian phân tích domain, xác định ranh giới giữa các tầng, thiết kế interface và thiết lập dependency trước khi triển khai chức năng. Điều này có thể làm tốc độ phát triển ban đầu chậm hơn so với các kiến trúc đơn giản.

- Yêu cầu kiến thức kiến trúc tốt: Để áp dụng hiệu quả, đội ngũ cần hiểu rõ các khái niệm như Dependency Inversion, Separation of Concerns, Abstraction và cách tổ chức trách nhiệm giữa các tầng. Nếu áp dụng máy móc, hệ thống có thể trở nên phức tạp nhưng không mang lại nhiều giá trị.

- Tăng lượng mã nguồn cần quản lý: Một nghiệp vụ đơn giản có thể phải đi qua nhiều thành phần như Controller, Use Case, Repository Interface và Repository Implementation. Số lượng file và class tăng lên khiến việc theo dõi codebase có thể khó khăn hơn nếu dự án chưa đạt quy mô phù hợp.
 

 

Lỗi thường gặp khi triển khai Clean Architecture & cách khắc phục 

Clean Architecture giúp hệ thống tách biệt rõ logic nghiệp vụ với các thành phần bên ngoài, nhưng việc áp dụng không đúng nguyên tắc có thể làm kiến trúc trở nên phức tạp và khó bảo trì hơn. Một số lỗi thường gặp liên quan đến việc thiết kế cấu trúc quá mức cần thiết, kiểm soát dependency chưa đúng hoặc phân bổ logic sai tầng. Nhận diện sớm những vấn đề này giúp đội ngũ duy trì được lợi ích của Clean Architecture mà không tạo thêm sự phức tạp không cần thiết.

1. Lỗi Over-Engineering: Áp dụng sai ngữ cảnh cho hệ thống CRUD quy mô nhỏ

Với các hệ thống CRUD quy mô nhỏ, developer vẫn triển khai đầy đủ Entities, Use Cases, Repository Interfaces, DTOs, Mappers, Presenters và nhiều lớp trung gian dù nghiệp vụ tương đối đơn giản. Một thao tác tạo, đọc, cập nhật hoặc xóa dữ liệu có thể phải đi qua nhiều class và interface khác nhau trước khi hoàn thành. Cách triển khai này làm tăng số lượng file, interface và đoạn mã cần quản lý trong khi giá trị mang lại không tương xứng với quy mô hệ thống.

Do đó trước khi áp dụng Clean Architecture, cần đánh giá quy mô, độ phức tạp nghiệp vụ, vòng đời và khả năng thay đổi của dự án. Với hệ thống CRUD nhỏ, có thể sử dụng cấu trúc đơn giản hơn và chỉ áp dụng những nguyên tắc cần thiết như Separation of Concerns và Dependency Inversion. Khi nghiệp vụ phát triển đến mức cần phân tách rõ Domain và Application Logic, đội ngũ có thể từng bước đưa các thành phần của Clean Architecture vào hệ thống.

2. Vi phạm quy tắc phụ thuộc: Rò rỉ hạ tầng vào tầng core

Domain Entities hoặc Use Cases trực tiếp import các thư viện, framework hoặc thành phần thuộc Infrastructure như ORM, database driver, HTTP framework hoặc SDK của bên thứ ba. Chẳng hạn, Entity chứa annotation của một ORM cụ thể hoặc Use Case trực tiếp gọi database client thay vì thông qua abstraction. Logic nghiệp vụ bị gắn chặt với công nghệ bên ngoài, làm giảm tính độc lập của tầng core. Khi thay đổi database, ORM hoặc framework, developer có thể phải chỉnh sửa cả Domain và Use Cases. Kiểm thử business logic cũng trở nên khó khăn hơn vì các thành phần cốt lõi phải phụ thuộc vào infrastructure thực tế.

Do đó, cần kiểm soát hướng dependency theo nguyên tắc của Clean Architecture: dependency từ tầng ngoài phải hướng vào tầng trong, không đi ngược lại. Use Cases chỉ nên phụ thuộc vào abstraction như Repository Interface hoặc các Ports cần thiết, trong khi Infrastructure chịu trách nhiệm triển khai những abstraction đó. Đồng thời, nên kiểm tra import và dependency của Domain, Use Cases trong quá trình code review để phát hiện sớm các thành phần hạ tầng bị rò rỉ vào core.  

3. Lạm dụng DTOs & Mappers gây ra quá nhiều mã thừa

Developer tạo quá nhiều DTO cho những dữ liệu có cấu trúc gần như giống nhau và xây dựng Mapper cho từng bước chuyển đổi dù không tồn tại khác biệt đáng kể giữa các model. Một request đơn giản có thể phải đi qua nhiều lớp DTO, Mapper và Response Model trước khi đến được Use Case hoặc giao diện. Số lượng class và đoạn mã chuyển đổi tăng nhanh, khiến project khó theo dõi và bảo trì. Những thay đổi nhỏ trong cấu trúc dữ liệu có thể phải cập nhật ở nhiều DTO và Mapper khác nhau. Nếu chuyển đổi không mang lại giá trị về mặt phân tách trách nhiệm, các abstraction này chỉ làm tăng boilerplate code và độ phức tạp của hệ thống. 

Vì thế, chỉ tạo DTO và Mapper khi chúng giải quyết một nhu cầu thực tế, chẳng hạn cần bảo vệ Domain Model, chuyển đổi giữa các boundary hoặc xử lý dữ liệu có cấu trúc khác nhau. Với những trường hợp dữ liệu đơn giản và không có ranh giới rõ ràng, có thể giảm số lớp trung gian và sử dụng cấu trúc dữ liệu phù hợp trực tiếp. Quan trọng nhất là mỗi DTO hoặc Mapper cần có lý do tồn tại rõ ràng thay vì được tạo chỉ để làm cho cấu trúc project có vẻ “đúng chuẩn”.  

4. Nhầm lẫn giữa luồng thực thi và chiều phụ thuộc

Một lỗi phổ biến khi triển khai Clean Architecture là đánh đồng luồng thực thi (execution flow) với chiều phụ thuộc (dependency direction). Chẳng hạn, khi người dùng gửi request, dữ liệu có thể được xử lý theo luồng Controller → Use Case → Repository → Database. Tuy nhiên, điều đó không có nghĩa là Use Case được phép phụ thuộc trực tiếp vào Repository Implementation hoặc Database.

Trong Clean Architecture, Use Case chỉ phụ thuộc vào Repository Interface được định nghĩa ở tầng bên trong, còn Repository Implementation nằm ở tầng ngoài sẽ thực hiện interface đó. Khi hiểu sai hai khái niệm này, developer dễ đưa dependency từ core ra ngoài và khiến Use Case phụ thuộc trực tiếp vào database, ORM hoặc framework. Điều này vi phạm Dependency Rule, làm business logic bị gắn với công nghệ cụ thể và trở nên khó kiểm thử hoặc thay đổi khi hệ thống phát triển.  

Khi thiết kế kiến trúc, cần tách biệt hai khái niệm này. Execution flow mô tả dữ liệu và quá trình xử lý diễn ra như thế nào, còn dependency direction xác định một class hoặc tầng phụ thuộc vào thành phần nào. Vì vậy, request vẫn có thể chạy theo hướng Controller → Use Case → Repository → Database, nhưng dependency phải hướng vào core: Use Case → Repository Interface ← Repository Implementation. Cách tổ chức này giúp Use Case chỉ biết đến abstraction thay vì phụ thuộc vào công nghệ lưu trữ cụ thể. 

5. Dồn ép logic nghiệp vụ vào Use Case thay vì Domain

Use Case chứa toàn bộ business rules, bao gồm cả các quy tắc liên quan trực tiếp đến trạng thái và hành vi của Entity. Trong khi đó, Domain Entity chủ yếu chỉ chứa thuộc tính và các getter/setter, gần giống một cấu trúc dữ liệu đơn thuần. Khi đó, Use Case có thể trở nên rất dài và phải xử lý nhiều chi tiết thuộc về Domain. Business logic bị phân tán hoặc tập trung sai vị trí, làm giảm tính gắn kết của Domain Model. Khi cùng một quy tắc nghiệp vụ được sử dụng ở nhiều Use Case, developer có nguy cơ phải viết lại logic hoặc tạo thêm các service trung gian. Điều này làm tăng nguy cơ duplicated logic và khiến thay đổi business rules trở nên khó kiểm soát.  

Nên đưa những business rules gắn trực tiếp với trạng thái, hành vi và invariant của Entity vào Domain. Use Case tập trung điều phối một quy trình nghiệp vụ: nhận Input, gọi các Domain objects cần thiết, phối hợp Repository hoặc các Port và trả về Output. Tuy nhiên, không nên đưa mọi logic vào Entity; những nghiệp vụ liên quan đến nhiều Entity hoặc không thuộc riêng một Entity có thể được tổ chức trong Domain Service. Cách phân bổ này giúp Domain giữ được business rules cốt lõi, trong khi Use Case đảm nhiệm vai trò điều phối. 

Qua bài viết của Phương Nam Vina, có thể thấy Clean Architecture là mô hình kiến trúc giúp tổ chức hệ thống theo hướng tách biệt rõ business logic với framework, database, giao diện và các dịch vụ bên ngoài. Việc kiểm soát dependency và đưa logic nghiệp vụ vào các tầng phù hợp giúp hệ thống dễ kiểm thử, bảo trì và thích ứng hơn khi yêu cầu hoặc công nghệ thay đổi. Tuy nhiên, Clean Architecture không phải lựa chọn bắt buộc cho mọi dự án. Hiệu quả của mô hình phụ thuộc vào quy mô, độ phức tạp nghiệp vụ, vòng đời và khả năng mở rộng của hệ thống. Nếu áp dụng quá mức cho những dự án nhỏ hoặc triển khai sai Dependency Rule, kiến trúc có thể trở nên phức tạp và tạo thêm mã nguồn không cần thiết. Vì vậy, điều quan trọng không nằm ở áp dụng đầy đủ mọi thành phần của Clean Architecture mà là lựa chọn và triển khai các nguyên tắc phù hợp với nhu cầu thực tế của dự án.

Tham khảo thêm:

 Micro Frontends là gì? Từ kiến trúc đến triển khai thực tế

 Microservices là gì? Cách triển khai microservices cho website

 Infrastructure as Code là gì? Lợi ích và các công cụ IaC phổ biến