Triển khai clean architecture trong Android

Trong bối cảnh công nghệ ngày càng phát triển nhanh chóng hiện nay, việc xây dựng phần mềm có khả năng mở rộng, bảo trì và kiểm thử trở nên vô cùng quan trọng. Một cách tiếp cận nổi bật để đạt được điều này là Kiến Trúc Sạch (Clean Architecture), một mô hình không chỉ hiệu quả mà còn rất tinh tế.

Clean architecture là gì?

Clean architecture nhấn mạnh việc tách ứng dụng thành các lớp riêng biệt, không gắn kết chặt chẽ, mỗi lớp đều có trách nhiệm được xác định rõ ràng.

Các phụ thuộc luôn hướng vào bên trong, đảm bảo rằng các phần quan trọng nhất của ứng dụng (như logic nghiệp vụ và thực thể) không phụ thuộc vào các framework bên ngoài.

Bằng cách sử dụng cấu trúc này, chúng ta có thể tạo ra một cơ sở mã nguồn thúc đẩy khả năng mở rộng, kiểm thử, và tái sử dụng. Nó giống như việc xây dựng với các khối Lego, mỗi khối (hoặc thành phần) có một vai trò riêng và có thể được thêm hoặc điều chỉnh khi ứng dụng phát triển.

Trong các phần tiếp theo, chúng ta sẽ khám phá các lớp cốt lõi của clean architecture, cách chúng tương tác và cách áp dụng chúng vào phát triển Android.

Các khái niệm cơ bản về clean architecture

Clean architecture dựa trên thiết kế phân lớp với mỗi lớp đảm nhiệm các trách nhiệm cụ thể. Cấu trúc này được chia thành bốn lớp chính:

1. Entities (thực thể)

Entities bao gồm các quy tắc nghiệp vụ ở mức cao. Chúng đại diện cho các đối tượng cốt lõi trong miền ứng dụng, thường là những phần trừu tượng và tổng quát nhất của hệ thống phần mềm.

Các thực thể này không phụ thuộc vào giao diện người dùng (UI), cơ sở dữ liệu, hay dịch vụ bên ngoài, chỉ tập trung vào logic nghiệp vụ.

// Ví dụ về thực thể trong ứng dụng blog có thể là một Post.
public class Post {
    private String title;
    private String body;

    // getters and setters
}

2. Use Cases (trường hợp sử dụng)

Use Cases (hay còn gọi là bộ tương tác) là logic nghiệp vụ định nghĩa các hoạt động mà hệ thống có thể thực hiện. Chúng làm việc với các thực thể và quyết định cách dữ liệu được tạo, sửa đổi, hoặc xóa.

Use Cases được cô lập và đảm bảo rằng các quy tắc nghiệp vụ không bị ảnh hưởng bởi giao diện người dùng hay các framework bên ngoài.

// Ví dụ về trường hợp sử dụng trong ứng dụng blog có thể là CreatePost.
public class CreatePost {
    private PostRepository postRepository;

    public CreatePost(PostRepository postRepository) {
        this.postRepository = postRepository;
    }

    public void execute(Post post) {
        postRepository.create(post);
    }
}

3. Interface Adapters (Bộ chuyển đổi giao diện)

Lớp này hoạt động như cầu nối giữa Use Cases và thế giới bên ngoài, chẳng hạn như cơ sở dữ liệu hoặc giao diện người dùng (UI).

Nó chuyển đổi dữ liệu từ định dạng này sang định dạng khác để đảm bảo cấu trúc dữ liệu phù hợp với những gì mà Use Cases hoặc Entities mong đợi. Interface Adapters chịu trách nhiệm chuẩn bị dữ liệu để hiển thị hoặc lưu trữ.

// Ví dụ về một bộ chuyển đổi giao diện có thể là PostPresenter.
public class PostPresenter {
    private View view;

    public PostPresenter(View view) {
        this.view = view;
    }

    public void present(Post post) {
        view.display(post.getTitle(), post.getBody());
    }

    public interface View {
        void display(String title, String body);
    }
}

4. Frameworks and Drivers (Framework và trình điều khiển)

Lớp ngoài cùng bao gồm tất cả các phụ thuộc và công cụ bên ngoài, chẳng hạn như cơ sở dữ liệu, dịch vụ web, và framework giao diện người dùng (UI).

Các công cụ này tương tác với phần còn lại của kiến trúc nhưng không nên ảnh hưởng trực tiếp đến các lớp cốt lõi, đảm bảo logic nghiệp vụ vẫn độc lập.

// Ví dụ từ Android có thể là Activity hoặc Fragment hiển thị các bài đăng.
public class PostActivity extends AppCompatActivity implements PostPresenter.View {
    private PostPresenter presenter;

    @Override
    protected void onCreate(Bundle savedInstanceState) {
        super.onCreate(savedInstanceState);
        setContentView(R.layout.activity_post);

        // Khởi tạo presenter và gọi một phương thức
        presenter = new PostPresenter(this);
        presenter.present(new Post("Title", "Body"));
    }

    @Override
    public void display(String title, String body) {
        // Cập nhật giao diện người dùng ở đây
    }
}

Quy tắc phụ thuộc (Dependency Rule)

Một quy tắc cơ bản là Quy tắc Phụ Thuộc. Quy tắc này quy định rằng các phụ thuộc nên hướng vào trong – từ các lớp ngoài đến các lớp trong.

Thực thể không nên phụ thuộc vào bất kỳ điều gì khác, các Use Cases chỉ nên phụ thuộc vào thực thể, và tương tự. Quy tắc này giúp duy trì sự tách biệt giữa các lớp, tạo ra một hệ thống dễ bảo trì và kiểm thử hơn.

Chuẩn bị cho clean architecture

1. Hiểu biết về Kiến trúc phần mềm: Trước khi triển khai clean architecture, cần nắm vững các nguyên tắc cơ bản về kiến trúc phần mềm.

2. Làm quen với các nguyên tắc SOLID: SOLID là viết tắt của năm nguyên tắc thiết kế nhằm làm cho thiết kế phần mềm dễ hiểu, linh hoạt và dễ bảo trì. Những nguyên tắc này là một phần cốt lõi của Kiến Trúc Sạch.

3. Kiến thức về Mẫu thiết kế: Các mẫu thiết kế giúp cấu trúc mã của bạn, giúp nó có tính mô-đun, tái sử dụng và dễ hiểu hơn. Các mẫu như Repository, Factory, hay Strategy rất quan trọng khi triển khai Kiến Trúc Sạch.

4. Kinh nghiệm về kiểm thử đơn vị (Unit Testing): clean architecture khuyến khích khả năng kiểm thử, vì vậy kiểm thử đơn vị đóng vai trò quan trọng. Cần hiểu rõ cách viết các bài kiểm thử đơn vị hiệu quả.

Thiết lập dự án với clean architecture

1. Modularization (Tách mô-đun) Việc chia nhỏ ứng dụng thành các mô-đun sẽ cải thiện khả năng triển khai Kiến Trúc Sạch.

2. Chọn thư viện phù hợp Việc triển khai clean architecture thường sử dụng các thư viện bên thứ ba cho các nhiệm vụ như Dependency Injection, các thao tác mạng, và quản lý cơ sở dữ liệu.

3. Cấu trúc thư mục Trong mỗi mô-đun, bạn có thể tổ chức các tệp thành các gói dựa trên chức năng của chúng.

4. Định nghĩa phụ thuộc Theo Quy tắc Phụ Thuộc, các lớp ngoài nên phụ thuộc vào các lớp trong.

Kiểm thử đơn vị trong Kiến Trúc Sạch

Clean architecture khuyến khích sự tách biệt giữa các mối quan tâm, giúp mã dễ kiểm thử hơn.

1. Kiểm thử các Entities và Use Cases

Use Cases là đối tượng quan trọng để kiểm thử đơn vị.

// Ví dụ đơn giản về kiểm thử đơn vị cho một Use Case
@Test
fun `test getAllPosts returns expected data`() = runBlocking {
    val mockRepo = mockk<PostRepository>()
    val posts = listOf(Post("1", "Title", "Content"))
    coEvery { mockRepo.getAllPosts() } returns posts

    val useCase = GetAllPosts(mockRepo)
    val result = useCase()

    assertEquals(posts, result)
    coVerify { mockRepo.getAllPosts() }
}

2. Kiểm thử Interface Adapters

ViewModel thường được sử dụng làm bộ chuyển đổi giao diện.

// Kiểm thử đơn vị cho ViewModel
@Test
fun `test PostViewModel gets all posts`() = runBlockingTest {
    val useCase = mockk<GetAllPosts>()
    val posts = listOf(Post("1", "Title", "Content"))
    coEvery { useCase() } returns posts

    val viewModel = PostViewModel(useCase)
    val result = viewModel.posts.getOrAwaitValue()

    assertEquals(posts, result)
}

Thách thức tiềm ẩn

Mặc dù clean architecture mang lại nhiều lợi ích như khả năng kiểm thử, tính độc lập khỏi giao diện người dùng (UI), cơ sở dữ liệu (DB), và các dịch vụ bên ngoài, cùng với sự tổ chức rõ ràng, nhưng cũng có những nhược điểm mà chúng ta cần cân nhắc.

• Phức tạp: clean architecture đòi hỏi phải có sự lập kế hoạch cẩn thận và hiểu rõ các quy tắc nghiệp vụ và thực thể. Đối với các dự án nhỏ, chi phí phát sinh có thể không đáng. Tuy nhiên, với các dự án vừa và lớn, quá trình thiết lập và lập kế hoạch ban đầu này có thể mang lại lợi ích đáng kể trong dài hạn.
• Đường cong học tập: clean architecture giới thiệu một số khái niệm mới như đảo ngược phụ thuộc (Inversion of Control), trường hợp sử dụng (Use Cases), và phân tầng nghiêm ngặt, có thể gây khó khăn cho nhiều lập trình viên. Việc nắm bắt những khái niệm này có thể mất thời gian.
• Tốc độ phát triển: Với sự gia tăng về độ phức tạp và đường cong học tập, clean architecture có thể làm chậm quá trình phát triển ban đầu. Tuy nhiên, điều quan trọng cần lưu ý là cách tiếp cận này có thể tăng tốc độ phát triển ở các giai đoạn sau của dự án, do ít lỗi hơn và việc thêm tính năng trở nên dễ dàng hơn.
• Quá trình phức tạp hóa: clean architecture khuyến khích một mức độ trừu tượng cao, và nếu không được quản lý đúng cách, có thể dẫn đến việc làm phức tạp hóa hệ thống (over-engineering).

Clean architecture là một cách tiếp cận đầy thú vị để cấu trúc các ứng dụng của chúng ta. Nó có thể giúp chúng ta đạt được mức độ trừu tượng cao, tăng khả năng kiểm thử, và tạo ra một mã nguồn tách biệt và có thể mở rộng.

Những lợi ích này đặc biệt hấp dẫn, nhất là đối với các dự án có quy mô vừa và lớn, nơi yêu cầu tính dễ bảo trì và khả năng mở rộng.

Clean architecture có thể là bước tiếp theo của bạn trong việc tạo ra các ứng dụng Android dễ quản lý, kiểm thử và phát triển hơn. Hãy dũng cảm, bước tiếp và tiếp tục lập trình!