huhu
Senior Member
Mình cũng là người áp dụng các nguyên lý trong Clean Architecture (CA) khá thường xuyên.
Mình có một số chia sẻ sau:
1. Về SOLID. Những nguyên lý ở mức class như SOLID thì mình thấy là anh em lập trình viên OO nên hoặc thậm chí phải nắm vững và áp dụng thường xuyên.
Ngay nay, DDD đang quay lại như một xu thế, và SOLID có thể được áp dụng tốt trong vùng từ Use Case Layer cho tới Domain Layer (2 vòng tròn trong cùng của Clean Architecture).
2. Về Component Principles. Đây là các nguyên lý hướng mình đến việc xây dựng ứng dụng từ các khối module. Nó vẫn rất ổn khi áp dụng vào 2 lớp trong.
3. Framework, là thứ mà Robert C. Martin (tác giả của Clean Architecture) rất hạn chế khuyên dùng. Ông thường nói Framework làm quá nhiều thứ mà mình không cần trong những ứng dụng cụ thể. Mình thì thấy không nên khắt khe quá. Mình vẫn dùng, nhưng ở tầng Adapters trong Hexagonal.
Đúng là áp dụng CA ngay ban đầu là khó và không nên.
4. Tham chiếu sang DDD, mình thấy có một hướng đi rất phù hợp như thế này. Trong tổ chức, phần mềm thường sẽ phục vụ một chiến lược kinh doanh nào đó. Và tổ chức đó hoạt động trong một domain. Mình cần xác định ra các subdomain. Có 3 loại:
a. Core subdomain: là nơi cần tối ưu để mang lại sự cạnh tranh với đối thủ trên thị trường. Ví dụ, mình viết ứng dụng bán hàng thì ứng dụng này phải đảm bảo yêu cầu như nhanh, chịu tải lớn, đáp ứng yêu cầu thử nghiệm nhanh nhất có thể. Vậy mình cần phải trang bị cho nó khả năng thay đổi thật nhanh về mặt logic. Vậy DDD với Domain Model là hướng đi hợp lý. Ngoài ra, ở đây phải tập hợp những con người giỏi nhất của tổ chức.
Bạn không thể cạnh tranh nếu như bạn triển khai ứng dụng trong vùng này bằng các giải pháp như Open source, vì đối thủ chẳng mấy chốc cũng bắt kịp bạn bằng chính giải pháp đó.
b. Supporting subdomain: là nơi có những ứng dụng mang tính hỗ trợ cho các ứng dụng core subdomain. Đây là nơi có thể áp dụng các cách lập trình đơn giản CRUD, không cần tối ưu nhiều. Nguồn lực con người cũng đặt vừa phải. Có thể là những người trẻ, cần trải nghiệm thêm.
c. Generic subdomain: là nơi mà mình không chú trọng, có thể mang tính công nghệ cao nhưng không thuộc chiến lược phát triển của công ty. Ví dụ như Map, ERP,... Những ứng dụng này mình có thể triển khai với open source hoặc mua trên thị trường.
5. Có một điều nữa là khi phát triển ứng dụng trong một domain mà chưa rõ nhiều về domain đó, theo kiểu trong giai đoạn startup cần thử nghiệm nhiều chẳng hạn, thì nên phát triển ứng dụng không phân chia ranh giới vật lý như Microservices, lúc đó nên sử dụng các nguyên lý CA để phân chia module rồi có thể triển khai trên một vài Monolith cũng được. Modular Monolith là bước chuẩn bị tốt để nếu sau này business tăng trưởng thì chuyển sang Microservices.
Tóm lại, mình thấy là các nguyên lý CA vẫn đúng, chỉ là khi nào cần áp dụng, ở phạm vi nào, nơi nào thôi. CA giúp code dễ bảo trì hơn nên mình nghĩ nếu bạn thấy boilerplate code nhiều thì có thể cách đóng gói component hiện tại đang có vấn đề. Và CA cũng nhấn mạnh rằng kiến trúc luôn thay đổi chứ không phải làm ra ban đầu là áp dụng mãi cho ứng dụng.
