Separation of Concerns trong phát triển di động — nó là gì, nguyên tắc và ứng dụng

Separation of Concerns là gì

Separation of Concerns là nguyên tắc phân rã một hệ thống phần mềm thành các phần độc lập, mỗi phần giải quyết một nhiệm vụ. Thuật ngữ concern (lĩnh vực trách nhiệm) chỉ bất kỳ phần có thể tách rời nào của chức năng: hiển thị màn hình, xử lý chạm, xác thực dữ liệu hoặc giao tiếp mạng. Nguyên tắc chỉ dẫn việc nhóm mã sao cho các thay đổi trong một lĩnh vực không yêu cầu thay đổi trong các lĩnh vực khác.

Trong phát triển di động, SoC thể hiện ở nhiều cấp độ: từ việc chia ứng dụng thành các màn hình đến tổ chức mã trong một lớp duy nhất. Một Activity hoặc ViewController đồng thời tải dữ liệu từ mạng, phân tích JSON và hiển thị UI vi phạm Separation of Concerns — loại mã này khó bảo trì, kiểm thử và mở rộng. Giải pháp thay thế là trích xuất mỗi trách nhiệm vào một thành phần riêng biệt.

Nguyên tắc này liên quan chặt chẽ đến khái niệm trừu tượng hóa: mỗi lớp cung cấp một giao diện được xác định chặt chẽ và ẩn chi tiết triển khai. Nhờ đó, nhà phát triển có thể thay thế thư viện mạng hoặc cơ sở dữ liệu mà không cần viết lại logic UI. Điều này đặc biệt có giá trị trong các dự án dài hạn, nơi các yêu cầu và công nghệ thay đổi theo thời gian.

Lịch sử và nguồn gốc của nguyên tắc

Edsger Dijkstra lần đầu tiên đưa ra ý tưởng về Separation of Concerns trong bài báo năm 1974 «On the Role of Scientific Thought». Ông lập luận rằng độ phức tạp của các hệ thống phần mềm có thể được kiểm soát bằng cách chia chúng thành các phần được phân tích riêng biệt. Cách tiếp cận này trái ngược với các chương trình nguyên khối thời đó, nơi mã trộn lẫn tính toán, nhập/xuất và giao diện người dùng.

Vào những năm 1980, ý tưởng này được phát triển bởi những người ủng hộ lập trình có cấu trúc, và sau đó là cách tiếp cận hướng đối tượng. Các ngôn ngữ như Smalltalk và C++ đã cung cấp các cơ chế đóng gói và mô-đun hóa, biến SoC thành một công cụ thực tế. Các mẫu kiến trúc hiện đại — MVC, MVP, MVVM và Clean Architecture — là hiện thân trực tiếp của nguyên tắc Separation of Concerns.

Trong thế giới phát triển di động, Apple đã thúc đẩy MVC như tiêu chuẩn cho iOS, nơi Model-View-Controller phân tách dữ liệu, hiển thị và logic điều khiển. Google cho Android đã đề xuất các hướng dẫn kiến trúc dựa trên ViewModel và Repository — mỗi thành phần giải quyết nhiệm vụ riêng của nó. Nếu không có SoC, các ứng dụng di động biến thành Massive View Controller — các lớp hàng nghìn dòng nơi bất kỳ thay đổi nào cũng có nguy cơ phá vỡ toàn bộ chức năng.

Các cấp độ phân tách trong kiến trúc di động

Bốn lớp chính tạo thành kiến trúc ứng dụng di động điển hình triển khai Separation of Concerns. Mỗi lớp chỉ chịu trách nhiệm cho lĩnh vực của mình và tương tác với các lớp lân cận thông qua giao diện.

Lớp UI: View và ViewModel

View chịu trách nhiệm duy nhất cho việc hiển thị dữ liệu và xử lý các sự kiện người dùng. Trong iOS, đó là UIViewController và UIView, trong Android — Fragment hoặc Activity. ViewModel chứa trạng thái màn hình và logic chuyển đổi dữ liệu thành định dạng sẵn sàng để hiển thị. Sự phân tách đảm bảo rằng việc thay thế UIKit bằng SwiftUI hoặc viết lại màn hình bằng Jetpack Compose không ảnh hưởng đến logic nghiệp vụ.

Kiểm thử ViewModel không yêu cầu chạy trình giả lập — chỉ cần kiểm thử đơn vị xác minh việc chuyển đổi dữ liệu và phản hồi với hành động người dùng. Đây là hệ quả trực tiếp của Separation of Concerns: UI không bị trộn lẫn với các quy tắc nghiệp vụ và mỗi thành phần được kiểm thử riêng biệt.

Lớp logic nghiệp vụ: Use Case và Interactor

Use Case (hoặc Interactor) chứa các quy tắc nghiệp vụ của ứng dụng — tính toán, xác thực, điều phối các cuộc gọi dữ liệu. Lớp này không biết về sự tồn tại của UI hoặc các framework nền tảng. Use Case nhận dữ liệu từ Repository, áp dụng logic và trả về kết quả đã hoàn chỉnh cho ViewModel. Sự phân tách cho phép tái sử dụng một Use Case trên nhiều màn hình khác nhau.

Ví dụ, LoginUseCase kiểm tra tính hợp lệ của email, gọi AuthRepository để xác thực và trả về kết quả. Nó không phụ thuộc vào giao diện màn hình đăng nhập — SwiftUI, UIKit hay Compose. Nếu các quy tắc nghiệp vụ thay đổi, chỉ cần sửa một Use Case mà không chạm đến UI hay cơ sở dữ liệu.

Lớp dữ liệu: Repository và DataSource

Repository trừu tượng hóa các nguồn dữ liệu: API từ xa, cơ sở dữ liệu cục bộ hoặc bộ nhớ đệm. ViewModel và Use Case không biết dữ liệu đến từ đâu — Repository quyết định tải từ mạng hay từ bộ nhớ đệm. Sự phân tách này cho phép thay đổi cách triển khai lưu trữ mà không ảnh hưởng đến logic nghiệp vụ hay UI.

DataSource là sự phân tách cấp thấp hơn: NetworkDataSource chỉ chịu trách nhiệm cho các yêu cầu HTTP, LocalDataSource — cho việc làm việc với Room hoặc CoreData. Repository kết hợp các cuộc gọi đến các DataSources khác nhau thành một giao diện nhất quán duy nhất. Mỗi DataSource được kiểm thử độc lập bằng cách sử dụng mock hoặc máy chủ giả.

Việc triển khai đúng đắn lớp DataSource đảm bảo rằng việc thay đổi lược đồ cơ sở dữ liệu hoặc thay thế REST API bằng GraphQL chỉ ảnh hưởng đến một DataSource, nhưng không ảnh hưởng đến Repository hoặc người tiêu dùng của nó. Đây là hệ quả trực tiếp của Separation of Concerns ở cấp độ cơ sở hạ tầng: mỗi mối quan tâm kỹ thuật được cách ly và có thể thay thế mà không có thay đổi dây chuyền.

SoC trong các mẫu thiết kế

MVVM (Model-View-ViewModel) là mẫu phổ biến nhất cho phát triển di động, triển khai trực tiếp Separation of Concerns. Model chứa dữ liệu và logic nghiệp vụ, View chịu trách nhiệm hiển thị, và ViewModel kết nối chúng thông qua các cơ chế phản ứng. Trong Flutter, BLoC đóng vai trò tương tự với sự phân tách thành sự kiện, trạng thái và logic nghiệp vụ.

Clean Architecture của Robert Martin (Uncle Bob) đưa SoC lên mức tối đa: hệ thống được chia thành các vòng độc lập — thực thể, use case, bộ điều hợp và framework. Các vòng bên trong (thực thể) không phụ thuộc vào các vòng bên ngoài (framework). Điều này cho phép thay đổi cơ sở dữ liệu, framework UI và thậm chí cả nền tảng mà không cần viết lại logic cốt lõi của ứng dụng.

Trong thực tế, các dự án di động hiếm khi triển khai Clean Architecture đầy đủ — đối với hầu hết các ứng dụng, kiến trúc ba lớp là đủ: UI, Miền và Dữ liệu. Lớp Miền chứa các Use Case và mô hình nghiệp vụ và hoàn toàn cách ly khỏi Android SDK hoặc iOS SDK. Sự phân tách như vậy mang lại 80% lợi ích với 20% công sức.

// Data layer — chỉ chịu trách nhiệm lấy dữ liệu
class UserRepository(private val api: UserApi) {
    suspend fun getUser(id: String): User = api.fetchUser(id)
}

// Domain layer — logic nghiệp vụ, không biết API hay cơ sở dữ liệu
class GetUserNameUseCase(
    private val repo: UserRepository
) {
    suspend fun invoke(id: String): String {
        val user = repo.getUser(id)
        return "${user.firstName} ${user.lastName}"
    }
}

// UI layer — chỉ hiển thị
class UserViewModel(
    private val getUserName: GetUserNameUseCase
) {
    fun onUserLoaded(id: String) {
        viewModelScope.launch {
            _name.value = getUserName.invoke(id)
        }
    }
}

Mã trên minh họa sự phân tách thuần túy: UserRepository chỉ làm việc với API, GetUserNameUseCase chứa logic nghiệp vụ định dạng tên, và UserViewModel quản lý trạng thái UI. Mỗi lớp có một lý do để thay đổi, đó là bản chất của Separation of Concerns.

Ưu điểm và hạn chế của Separation of Concerns

Ưu điểm chính của SoC là khả năng bảo trì. Mã được chia thành các lớp độc lập dễ phân tích hơn: nhà phát triển chỉ nhìn vào lớp nơi xảy ra lỗi và không bị phân tâm bởi các lớp khác. Trong các dự án dài hạn, điều này giảm thời gian tìm và sửa lỗi từ 30–50% so với mã nguyên khối.

Ưu điểm quan trọng thứ hai là khả năng kiểm thử. Khi logic nghiệp vụ được cách ly khỏi UI và các framework, nó được bao phủ bởi các kiểm thử đơn vị mà không cần chạy trình giả lập. Các dự án Android và iOS với độ bao phủ kiểm thử đơn vị cao có ít hồi quy hơn đáng kể khi thêm các tính năng mới.

Hạn chế chính là sự gia tăng độ phức tạp. Việc phân mảnh quá mức thành các vi lớp và trừu tượng dẫn đến việc thêm một nút đơn giản, nhà phát triển phải chỉnh sửa năm tệp. Nguyên tắc Separation of Concerns đòi hỏi sự cân bằng hợp lý: chỉ phân tách những lĩnh vực thực sự thay đổi độc lập. Đối với các dự án nhỏ, sự phân tách cơ bản thành UI, logic và dữ liệu mà không có các trừu tượng bổ sung là đủ.