Clean Architecture Android
Trong quá khứ chúng ta có thể đã được học rất nhiều Software Architecture từ thời còn ngồi trên ghế nhà trường. Nhưng gần đây chúng ta đã được tiếp cận với một số kiến trúc mới như MVVM, MVP, VIPER và nhiều mô hình khác.
Nhưng trong bài viết này ta sẽ không đi vào giải thích các mô hình kiến trúc trên. Ta sẽ cùng nhau đi giải thích cho câu hỏi: Tại sao lại phải sử dụng các kiến trúc vào trong project, và làm sao để có được một kiến trúc tốt nhất.
Một kiến trúc tốt là như thế nào?
Một kiến trúc đủ mạnh đủ tốt (Clean Architecture) sẽ luôn đảm bảo tính scale và maintain. Giả sử ta cần làm thêm một tính năng mới hoặc cần thay cập nhật tính năng cũ đúng với nhu cầu người dùng. Nó ảnh hưởng tới toàn app nhưng vẫn đảm bảo lỗi phát sinh thấp nhất có thể và kịp thời gian release.
Một kiến trúc tệ là khi các (layer) bị ràng buộc(deeply couple) - phụ thuộc(dependency) chặt chẽ với nhau. Khi có bất cứ thay đổi — giả sử thêm hoặc sửa 1 model !! Oop !
Tại sao một kiến trúc tốt lại có thể làm được điều đó ?
Vì nó đủ tách biệt(decouple) giữa các tầng (layer) trong kiến trúc, mỗi tầng sẽ đảm nhiệm các nhiệm vụ riêng, để khi ta update thì sẽ ít bị ảnh hưởng nhất có thể. Tại sao nó lại như vậy? Đó là một phần nhờ vào SOLID và nhiều design pattern khác.
Tại sao lại là Clean hơn ?
- Tách biệt giữa các layer với các nhiệm vụ riêng của nó, làm cho nó dễ dàng sửa đổi.
- Trừu tượng nhất có thể trên các class high level (high và low-level trong nguyên lý DI)
- Khi apply Testing sẽ ít đau đớn hơn.
“Clean code always looks like it was written by someone who cares.”
— Michael Feathers
Các Layers ?
Thường trong project sẽ có rất nhiều layer khác nhau, nhưng ta sẽ focus vào các layer chính:
Domain Layer: Nó có thể thực hiện các logic về nghiệp vụ, nó độc lập với tất cả các layer khác. Trong Android nó sẽ chỉ là các class với Kotlin hoặc Java thuần túy, không có bất cứ class nào liên quan tới Android class ( như View, context, v.v.v). Thường sẽ bao gồm các packages :
- Common, Entities : …. Utils, common, data entity classs.
- Reposittories: Là các interface tính năng mà usecase sử dụng, nó được implement tại data layer.
- Usecase : Thường chứa các class usecase là các class thực thi các logic của ứng dụng. Mỗi logic sẽ được chia ra thành các class riêng -Ex: LoginUsecase, NewsUsecase, ShipperUsecase.
Data Layer: Nó có thể cung cấp các data được yêu cầu cho toàn ứng dụng thông qua các interface được cung cấp bởi tầng domain. Data layer nên được thiết kế để có thể re-used tron ứng dụng và ít bị ảnh hưởng nhất có thể khi thay đổi logic. Thường sẽ bao gồm các packages :
- API: Cung cấp remote network implement (Retrofit, Voley)
- DB: Local storage (Room, SQLite, Realm)
- Entites: Data entity class được sử dụng trong data layer
- Repository: Class implement cụ thể cho từng tính năng mà tầng Domain cần- Ex: getShipperInfo() get data từ DB local hay call API.
Presentation Layer: Layer quyết định sẽ hiển thị gì và nhận input gì từ giao diện người dùng. Tầng này sẽ thường sẽ được implement bởi các kiến trúc như MVP, MVVM, MVC, MVI, etc. Thườn sẽ bao gồm các package như :
- DI:(Dependency Injection) Để tăng tính tách biệt(Decouple) giảm sự phụ thuộc giữa layer Presentation và các layer khác. Nhiệm vụ của DI là inject các usecase của tầng domain vào layer presentation.
- Entities: Data class sẽ được hiển thị lên cho user và nhận các tương tác từ user.
- Mappers: Mapping Entity từ các layer khác tới layer Presentation và ngược lại.
- Presenter (ViewModel- Controller) ..etc Nhận và xử lý tất cả event tương tác từ user và control hiển thị nội dung cho View.
- Views: Các lớp chứa views. Là một views càng dumb(thụ động) càng make clear. Ex: show(), hide(), showToast(), showShipper(), onClick, etc.
Flow của ứng dụng:
Tổng kết.
Sau bài viết này ta đã có những cái nhìn tổng quan về một kiến trúc tốt là như thế nào. Hi vọng nó sẽ giúp ích với mọi người. Nếu bài viết còn thiếu sót hay nội dung chưa phù hợp hãy response cho mình ở dưới dây. Rất mong các đóng góp của mọi người.
