Clean Architecture là gì ? Những khái niệm cơ bản ?

Clean Architecture là gì ? Clean Architecture(Kiến trúc sạch) được xây dựng dựa trên tư tưởng “độc lập” kết hợp với các nguyên lý thiết kế hướng đối tượng(đại diện tiêu biểu là Dependency Inversion). Độc lập ở đây nghĩa là việc project không bị phụ thuộc vào framework và các công cụ sử dụng trong quá trình kiểm thử.

Đặt vấn đề

Bạn đã từng thực hiện code mà:

• Gây lỗi nặng nề.
• Khổ sở để debug hoặc mở rộng với những tính năng mới.
• Khó hoặc không thể test nếu không có những thứ như database hoặc web server.
• Có tầng presentation được trộn lẫn với business logic hoặc business logic được trộn với data acccess logic.
• Khó để cho các lập trình viên khác hiểu bởi vì nó không thể hiện rõ ràng ý định hoặc mục đích trong ứng dụng như code đã viết.

Tôi biết tôi đã từng như thế. Qua thời gian tôi đã học về những patterns khác nhau và đã nỗ lực một cách có ý thức để giữ cho các nguyên tắc cứng rắn chạy trên một luồng ngầm định trong tư duy của tôi khi tôi viết code. Trong khi những ý tưởng này chắc chắn đã giúp giảm thiểu các vấn đề được liệt kê ở trên, tuy nhiên vấn đề không hoàn toàn bị loại bỏ. Khi viết phần mềm web hoặc desktop sử dụng MVC hoặc MVM tôi vẫn tìm ra một triệu chứng giống như trong các dự án trước đó của của tôi. Những thứ như business logic rò rỉ đến controllers, entry models được sử dụng trên tất cả các nơi cho những những mục đích khác nhau của code mà không có unit test để coverage bởi vì chúng có một vài sắp xếp sự phụ thuộc trên database và http client.

Câu trả lời

Một ngày, một khóa học đã gửi link giới thiệu The Clean Architecture bởi Uncle Bob. Nó gây chú ý với tôi ngay lập tức như nó đã trình diễn một giải pháp cho các vấn đề giống nhau mà tôi đang gặp. Phần tốt nhất, đó là không có gì thần bí hay phức tập về Clear Architechture. Nó là một architechture template tương đối đơn giản và có thể áp dụng tới nhiều mảng ứng dụng nếu bạn chọn để làm theo chỉ một vài quy định cơ bản.

Clean Architecture hoạt động như thế nào?

Quy tắc chính bên trong của Clean Architecture là: Dependency Rule. Ý chính của điều này chỉ đơn giản là các phụ thuộc được gói gọn trong mỗi “vòng” của mô hình kiến trúc và các phụ thuộc này chỉ có thể hướng vào trong. Kiến trúc của Clean Architecture chia thành 4 layer với một quy tắc phụ thuộc. Các layer bên trong không nên biết bất kỳ điều gì về các layer bên ngoài. Điều này có nghĩa là nó có quan hệ phụ thuộc nên “hướng” vào bên trong. Nhìn vào hình vẽ minh họa sau đây:

Entities: là khái niệm dùng để mô tả các Business Logic. Đây là layer quan trọng nhất, là nơi bạn thực hiện giải quyết các vấn đề – mục đích khi xây dựng app. Layer này không chứa bất kỳ một framework nào, bạn có thể chạy nó mà không cần emulator. Nó giúp bạn dễ dàng test, maintain và develop phần business logic.

Use case : chứa các rule liên quan trực tiếp tới ứng dụng cục bộ (application-specific business rules).

Interface Adapter : tập hợp các adapter phục vụ quá trình tương tác với các công nghệ.

Framework and Drivers : chứa các công cụ về cơ sở dữ liệu và các framework, thông thường bạn sẽ không phải lập trình nhiều ở tầng này. Tuy nhiên cần chắc chắn về mức ưu tiên sử dụng các công cụ này trong project.

====>>>> Code của các class thuộc lớp trong không được tham chiếu đến code của class thuộc lớp ngoài.

Thông thường thì một ứng dụng của bạn có thể có tùy ý số lượng các layer. Thường thì một ứng dụng Android sẽ có 3 layer:

• Outer: Implementation layer: là nơi mà tất cả mọi thứ của framwork xảy ra, điều này bao gồm tất cả các công cụ Android như là tạo các activity, các fragment, gửi intent, networking và databases.
• Middle: Interface adapter layer: là hoạt động như một kết nối giữa business logic và framework specific code.
• Inner: Business logic layer: tương tự như trên.

Có phải bắt buộc là bốn layer ?

• Clean architecture không bắt buộc chỉ có 4 layer. Tuỳ theo hệ thống, chúng ta có thể chia thành nhiều layer hơn.
• Không có rule nào bắt buộc chỉ có 4 layer nhưng clean architecture phải tuyệt đối tuân thủ vào dependency rule.
• Khi chúng ta đi vào trong từ layer level cao xuống các layer thấp hơn, mức độ trừu tượng hoá sẽ được tăng lên (mức độ phụ thuộc giảm đi) do đó chúng ta càng dễ tách biệt chúng để dễ dàng kiểm thử, maintain và thay đổi hơn.
• Do đó, vòng tròn trong cùng là chung nhất. Chúng ta có thể chạy nó độc lập mà không sợ bị lỗi.

Crossing boundaries

• Hình ảnh trên minh hoạ cho crossing boundaries, nó chỉ ra việc kết nối giữa use cases và interface adapters. Khi thực hiện use cases, phần lớn sẽ đều liên quan tới interface adapters. Trong suy nghĩ, chúng ta sẽ cần các implement của interface adapters để thực hiện các use case.
• Nhưng theo điều 1, use cases không thể có source code của interface adapters. Vậy chúng ta phải làm như thế nào ?
• Chúng ta giải quyết vấn đề này bằng dependency inversion principle.
• Ví dụ: trong Java, chúng ta sẽ sử dụng interface và quan hệ kế thừa. Các use case sẽ sử dụng interface để trừu tượng hoá việc thực hiện của mình. Sau đó các component của interface adapters sẽ implement các interface đó.

Data cross boundaries

• Thông thường, data là những cấu trúc dữ liệu đơn giản nhất. Nó có thể là POJO object, basic structs…
• Chúng ta không thể dùng chung data xuyên suốt ứng dụng bởi vì theo điều 2, các layer cấp cao hơn không làm thay đổi layer thấp hơn. Nếu chúng ta chỉ sử dụng chung data thì layer level có thể làm thay đổi data đó.
• Điều quan trọng ở đây là hãy tách biệt và đơn giản hoá data ở các layer.
• Ví dụ: Ở entities, chúng ta có Movie là movie data của hệ thống. Ở interface adapters, chúng ta chỉ muốn lưu một số property của movie vào database. Để tách biệt với entities, trong interface adapters, chúng ta phải tạo ra 1 MovieRow object để làm việc với database.

Kết luận

• Việc tuân thủ theo clean architecture là không khó, nó giúp chúng ta giảm đi nhiều rủi ro có thể gặp phải.
• Với việc tách biệt thành các layer và tuân theo dependecy rule, hệ thống của chúng ta sẽ dễ dàng test, maintain và thay đổi.
• Khi một thành phần như giao diện, database work…bị lỗi thời, chúng ta có thể dễ dàng thay thế nó với effort bỏ ra là ít nhất.