Một điều quan trọng khi học microservices là bạn phải nghĩ về business trước, tức là bài toán của chúng ta là gì, làm sao chúng ta chia nhỏ ra để giải quyết từng phần một cách dễ dàng, và làm sao kết hợp các phần đó lại để giải bài toán lớn.

Một cái bẫy các bạn hay rơi vào là tập trung vào lý do: microservices giúp tăng tính scalability, thực ra scalability là việc riêng của từng microservice. CQRS, caching, autoscaler… là chuyện riêng của từng microservice.

Về tổng thể toàn bộ hệ thống sẽ được hưởng lợi bởi chúng ta có thể tăng tính scalability lên từng phần, những phần nào chịu tải lớn hơn sẽ được thiết kế và triển khai khác, phục vụ cho lượng lớn người dùng, và ngược lại.

Tuy nhiên microservices có một lý do tồn tại khác nữa: Chúng ta có thể chia nhỏ vấn đề để giải quyết dễ dàng hơn, bởi khi có nhiều bài toán nhỏ, chúng ta có thể chia cho nhiều nhóm phát triển đồng thời, tổ chức nhóm cũng đơn giản hơn, rào cản gia nhập dự án thấp hơn vì không cần kiến thức về toàn bộ hệ thống, các lỗi có thể xác định và sửa dễ dàng hơn trong một microservice hơn là cả hệ thống lớn… Cũng như việc giải nhiều bài toán dễ thường sẽ đơn giản hơn giải một bài toán khó.

Bạn có nhớ đến một quy tắc quan trọng trong microservices: Database per Service? Hãy thử bỏ qua quy tắc này, bạn sẽ thấy nhiều ưu điểm kể trên biến mất.

Vì lý do trên, có một thứ mà bạn nên quan tâm, thậm chí là một trong những vấn đề đầu tiên và quan trọng nhất: chia nhỏ bài toán thành các microservice như thế nào? Vấn đề tương tự cũng xảy ra với Clean Architecture, ngay lập tức bạn nghĩ tới Inversion of Control, tới cấu trúc thư mục, tới cách chia thành các module… Nhưng vấn đề quan trọng nhất lại là: Các entity hoặc use case (domain service) trong bài toán của bạn là gì? Tất cả những thứ còn lại đều là hệ quả của cách bạn chọn ra entity và use case trước đó.

Vậy nên nếu vẫn chưa hiểu được các kiến trúc trên, bạn hãy thay đổi cách tiếp cận xem sao?