Kiến trúc Modular Monolith được giải thích: Xây dựng có kỷ luật

Nếu Kiến trúc Monolithic là một tòa nhà đơn lẻ, lộn xộn và Microservices là một thành phố phân tán, thì Modular Monolith là một tổ hợp văn phòng nhiều tầng, được tổ chức tốt. Nó tận dụng sự đơn giản của monolith và áp dụng kỷ luật nghiêm ngặt vào cấu trúc bên trong của nó.

Modular Monolith chính xác là gì?

Modular Monolith là một mẫu kiến trúc trong đó toàn bộ ứng dụng vẫn được triển khai dưới dạng một đơn vị duy nhất, nhưng mã được phân tách thành các module độc lập, được xác định rõ ràng dựa trên các lĩnh vực nghiệp vụ.

• Đơn vị triển khai đơn lẻ: Giống như một monolith truyền thống, nó được triển khai dưới dạng một quy trình duy nhất (thường chia sẻ cùng một cơ sở dữ liệu)
   

• Ranh giới nghiêm ngặt: Các module thực thi sự phân tách rõ ràng. Một module "Thanh toán" không thể trực tiếp gọi mã nội bộ hoặc bảng cơ sở dữ liệu của module "Hàng tồn kho". Giao tiếp chỉ xảy ra thông qua các giao diện công khai được xác định (API nội bộ)
   

• Tập trung vào lĩnh vực: Mỗi module gói gọn giao diện người dùng, logic nghiệp vụ và quyền truy cập dữ liệu riêng cho một lĩnh vực cụ thể

Mặt tốt của sự kỷ luật

Modular Monolith cung cấp sự cân bằng tuyệt vời cho nhiều công ty:

• Sự đơn giản của việc triển khai: Bạn vẫn chỉ có một thứ để triển khai và quản lý, tránh gánh nặng vận hành khổng lồ của microservices
   

• Quyền sở hữu & Bảo trì rõ ràng: Các nhóm có thể sở hữu và làm việc trên một module mà không sợ làm hỏng các phần khác của ứng dụng, cải thiện đáng kể sự nhanh nhẹn nội bộ
   

• An toàn khi tái cấu trúc: Các ranh giới module rõ ràng, được thực thi giúp việc tái cấu trúc hoặc nâng cấp công nghệ trên quy mô lớn trong một module trở nên an toàn hơn nhiều
   

• Dễ dàng làm bàn đạp: Vì các ranh giới đã được thiết lập, việc trích xuất một module thành một microservice hoàn toàn độc lập sau này dễ dàng hơn nhiều (thường sử dụng Strangler Fig Pattern).

Những thách thức của sự phát triển có kiểm soát

Mặc dù nó tránh được sự phức tạp lớn nhất của microservice, nó vẫn có những hạn chế:

• Tăng quy mô bắt buộc: Vì nó là một đơn vị duy nhất, bạn vẫn phải mở rộng toàn bộ monolith, ngay cả khi chỉ một module đang chịu tải
   

• Giao tiếp nội bộ vẫn cục bộ: Các module giao tiếp thông qua các lệnh gọi hàm đơn giản (không phải lệnh gọi mạng), có nghĩa là một module gặp sự cố vẫn có khả năng làm sập toàn bộ ứng dụng
   

• Yêu cầu kỷ luật: Nếu không có các công cụ tự động (như kiểm tra kiến trúc hoặc tiện ích quản lý gói) để thực thi các ranh giới, một Modular Monolith có thể dễ dàng bị thoái hóa trở lại thành một monolith truyền thống, được kết hợp chặt chẽ
   

• Tài nguyên dùng chung: Cơ sở dữ liệu dùng chung vẫn có thể trở thành điểm tranh chấp và tắc nghẽn nếu không được quản lý cẩn thận.

Khi nào nó có ý nghĩa?

Kiến trúc này là lý tưởng cho các ứng dụng mới hoặc cỡ vừa dự kiến sẽ tăng trưởng nhưng chưa biện minh cho sự phức tạp và chi phí cao của một hệ thống phân tán. Nó cũng là một lựa chọn tuyệt vời cho các nhóm coi trọng tốc độ và sự đơn giản trong việc triển khai nhưng muốn duy trì một cơ sở mã sạch, được tổ chức và có thể phát triển.