UI Framework & Architecture
Trong các chương trước, ta đã bàn về logic, data, testing, DI… nhưng chưa chạm đến UI. Đó là cố ý.
Chương này giải thích tại sao UI nên là thứ code cuối cùng.
1. Hoãn việc code UI
Phần tiêu đề “1. Hoãn việc code UI”Là mobile developer, ta thường muốn nhảy vào code UI ngay vì nó “vui” và thấy kết quả ngay.
Tuy nhiên, trong system design, UI thường là thứ thay đổi nhiều nhất và dễ khiến ta mất focus khỏi các quyết định kiến trúc quan trọng hơn.
Nguyên tắc: Hãy code business logic như thể app của bạn chạy trên command line (không có UI). Nếu logic chạy tốt qua CLI hoặc test mà không cần UI, thì kiến trúc đã được decouple tốt.
2. Architecture thay đổi theo “mùa”
Phần tiêu đề “2. Architecture thay đổi theo “mùa””MVC, MVVM, MVP, VIPER, MVI, TCA…
Các UI architecture đến rồi đi. Nếu bạn couple business logic vào một architecture cụ thể (ví dụ: logic nằm hết trong ViewModel), thì khi trend chuyển sang architecture khác, bạn phải viết lại rất nhiều.
Architecture thật sự của app nên nằm ở business logic layer — nơi nó không phụ thuộc vào UIKit, SwiftUI, XML hay Jetpack Compose.
3. Decouple logic khỏi UI
Phần tiêu đề “3. Decouple logic khỏi UI”Để đạt được điều này:
- UI chỉ là presentation layer: Hiển thị data và nhận user interaction. Không hơn.
- Business logic không biết về UI: Các class như
PaymentService,CourseManagerkhông import UI framework. - Dùng Protocol/Interface: UI giao tiếp với logic qua abstraction layer.
4. Hỗ trợ nhiều target
Phần tiêu đề “4. Hỗ trợ nhiều target”Khi decouple tốt, bạn có thể reuse logic cho nhiều target:
- Main app: UI đầy đủ animation.
- Widget / Extension: UI rút gọn, cùng business logic.
- CLI tool (internal): Debug, tạo test data mà không cần mở simulator.
Kết luận: Đừng để UI framework hay UI architecture dominate kiến trúc app. Giữ business logic “pure” và để UI chỉ là presentation layer bên ngoài.