Chia sẻ kiến trúc - Giải thích Clean Architecture

Trong video này mình chủ yếu chia sẻ về ý tưởng, triết lý và các đặc tính quan trọng của Clean Architecture. Một lỗi sai mình thường thấy nhất là các bạn hiểu sai cái Dependency Rule nên phần nào gây nhầm lẫn và khó triển khai.

1. Triết lý của Clean Architecture giống với Hexagonal và Onion Architecture: cô lập và lấy business logic làm trọng tâm (có thể gọi là Domain). Bên ngoài giao tiếp thông qua các Ports: Input và Output.

2. Các vòng tròn ở ngoài cùng là chi tiết nhất (low-level/details), trong cùng là high level (trừu tượng).

3. Cái "mũi tên" trong ảnh Clean Architecture không phải là "call direction" mà là "dependency direction". Bởi vì:

4. Clean Architecture sử dụng Dependency Inversion (DI) - chữ D trong SOLID.
High level không phụ thuộc vào low level, chúng lệ thuộc abstraction.
Abstraction không lệ thuộc vào implements/details của nó.

Từ đó các thay đổi từ các tầng low-level (chi tiết) không gây ảnh hưởng gì đến Domain ở trong. Và domain dễ dàng test, maintain một cách độc lập.

Khi implement Clean Architecture thì cấu trúc thư mục, cách phân chia package sao cũng được, miễn thoả các đặc tính trên.

Thường để đảm bảo DI, các SE kinh nghiệm thường khai báo các interfaces cần thiết ở trong domain, sau đó viết business logic, mocktesting các kiểu xong hết mới đi xử các tầng details bên ngoài: Như DB, HTTP Handlers,...

Cách này có thể gọi là Use Case first hoặc Doman Driven. Tuy nhiên để gọi là DDD và làm đúng và đủ thì còn khá nhiều thứ nữa.

Có thời gian mình sẽ nói DDD sau!!!