Đặc điểm của Clean Architecture - Part 1: Rule, Entities và Use-Cases

1. Tổng quan về thế giới architecture

Hơn nhiều năm gần đây, xuất hiện nhiều đề xuất liên quan đến tổ chức code sao cho hợp lý nhất bao gồm Hexagonal, Screaming hay Onion. Các bạn search google để tìm hiểu thêm.

Mặc dù các kiến trúc này đều hơi hơi khác nhau, nhưng chúng rất giống nhau ở chỗ đó là các phần phải tách biệt nhau, càng tách biệt càng tốt. Tất cả đều có những cách giải quyết riêng dựa trên việc chia phần mềm thành các layer. Và mỗi layer phải có những business rule riêng và 1 layer cho các interface.

Nhìn chung, điểm tương đồng là:

1. Sự độc lập của Frameworks (Independent of Frameworks). Kiến trúc phải không phụ thuộc vào các library là ta dùng. Bạn dùng framework như một cái tool thay vì nhét chúng vào thành các ràng buộc cố định (Ví dụ nha, khi bạn dùng Realm, class của bạn phải conform class Object và các biến phải là dynamic, bây giờ nếu bạn đổi sang SQL thì bạn phải xoá các dynamic đi. Như vậy đâu có độc lập)
2. Testable. Các business rules có thể được test mà không cần UI, Database, Web Server hay những thành phần bên ngoài khác. Ở đây chỉ cần mocking data là được.
3. Sự độc lập của UI (Independent of UI). UI có thể thay đổi dễ dàng mà không ảnh hưởng gì đến toàn bộ hệ thống. Ví dụ 1 UITextfield có thể thay bằng console UI mà không ảnh hưởng gì đến business rule.
4. Sự độc lập của Database (Independent of Database). Bạn dùng Realm hay CoreDate hay gì đi nữa thì business rule của bạn cũng chả quan tâm
5. Sự độc lập của các lib (Independent of any external agency). Đơn giản là business rules của bạn không biết bất cứ cái thay đổi gì ở các lib.

2. Dependency rule

Các vòng tròn đại diện cho từng phần. Quy tắc là bạn càng đi sâu vào, level càng tăng lên. Vòng bên ngoài là cơ chế, bên trong là quy tắc.

Dependenncy rule nói là source code chỉ có thể chỉ ngược vào bên trong. Và nó sẽ không biết bất cứ cái gì ở bên ngoài. Cụ thể, tên của function, class, variable hay bất kì entity được khai báo ở vòng tròn ngoài sẽ không được gọi ở vòng tròn trong (bởi vì bên trong có biết gì bên ngoài đâu)

Tương tự, các format của data được sử dụng ở vòng tròn ngoài không nên được sử dụng lại bởi 1 vòng tròn bên trong, đặc biệt là khi những format này được gen bởi 1 framework trong vòng tròn ngoài

Tóm lại, bản chất là không muốn bất cứ cái gì ở ngoài ảnh hưởng đến ở trong.

3. Entities là gì ?

Entities đóng gói (encapsulate) các business rule của trên toàn bộ app của bạn. Một entity có thể là 1 object với các methods, có thể là 1 tập các data structures, functions. Không quan trọng là gì, miễn là các entities này có thể được sử dụng ở nhiều chỗ khác nhau trong luồng targer app.

Trong 1 ứng dụng đơn giản, thì entities chính là các objects. Chúng đóng gói các rule chung và high-level nhất. Vì chúng ít có khả năng thay đổi nhất khi một cái gì đó bên ngoài thay đổi. Vì nếu mà objects bị ảnh hưởng vì page navigation thì cạn lời. Từ ví dụ về objects, ta cũng đúc kết được là những thay đổi cụ thể trên app sẽ không làm ảnh hưởng đến các entities.

4. Khái niệm Use Cases

Lớp layer này chứa những business rule cụ thể hơn. Nó đóng gói và thiết lập tất cả use case của hệ thống. Những use case này sắp xếp flow data từ thực thể, và hướng các thực thể này dùng các business rule để giải quyết mục đích của use case.

Layer này không nên bị ảnh hưởng bởi những thay đổi của các yếu tố bên ngoài như database, UI, hoặc bất kỳ framework nào. Layer này được phân tách khỏi những mối quan hệ như thế.

Tuy nhiên, chúng ta lại muốn những thay đổi trong việc hoạt động của ứng dụng sẽ ảnh hưởng đến use case, và tất cả code trong layer này. Nếu chi tiết của một use case thay đổi, thì nhiều đoạn code trong layer này cũng cần thay đổi tương ứng.