Kiến trúc phần mềm theo module nghĩa là chia hệ thống thành các khối có nhiệm vụ rõ ràng (bán hàng, kho, nhân sự, báo cáo), mỗi khối có dữ liệu và quy tắc riêng, nói chuyện với nhau qua những cổng đã định sẵn. Lợi ích với chủ doanh nghiệp rất cụ thể: làm trước khối cần nhất, thêm khối khác sau, và sửa một khối không làm hỏng các khối còn lại.
Chia module không phải là chia thành nhiều phần mềm riêng rẽ. Đó vẫn là một hệ thống thống nhất, một đăng nhập, một cơ sở dữ liệu chung, nhưng bên trong được sắp xếp có trật tự giống như một văn phòng có các phòng ban rõ ràng thay vì một căn phòng lớn để mọi thứ lẫn lộn.
Vì sao module quan trọng với doanh nghiệp
Phần mềm quản lý hiếm khi xong một lần. Doanh nghiệp bắt đầu từ đơn hàng, vài tháng sau cần kho, sau nữa cần nhân sự, rồi báo cáo cho ban giám đốc. Nếu hệ thống ban đầu không chia module, mỗi lần thêm tính năng là một lần chạm vào mọi thứ, và rủi ro lỗi tăng dần.
Chia module tốt cho bạn ba điều:
- Giao theo giai đoạn: làm module quan trọng nhất trước, đưa vào dùng, rồi mở rộng
- Phân công rõ: lỗi ở đâu thì sửa ở đó, không phải dò cả hệ thống
- Thay thế được: sau vài năm, một module có thể viết lại mà không phải bỏ cả phần mềm
Cách làm này đi cùng nguyên tắc giao theo giai đoạn mà chúng tôi áp dụng: một bản đầu nhỏ chạy thật, sau đó mở rộng dần.
Ví dụ chia module cho doanh nghiệp bán hàng (tình huống giả định)
Giả sử một doanh nghiệp bán hàng có kho và nhân viên kinh doanh. Một cách chia hợp lý:
- Danh mục: sản phẩm, đơn vị tính, bảng giá. Nhiều module khác cùng đọc từ đây
- Khách hàng: thông tin liên hệ, lịch sử giao dịch, công nợ
- Bán hàng: báo giá, đơn hàng, trạng thái giao hàng
- Kho: nhập, xuất, tồn kho, kiểm kê
- Nhân sự: hồ sơ nhân viên, chấm công, phân công
- Báo cáo: tổng hợp từ các module trên, không tự lưu dữ liệu gốc
- Người dùng và phân quyền: ai được xem, ai được sửa phần nào
Điểm mấu chốt: mỗi dữ liệu có đúng một nơi chịu trách nhiệm. Tồn kho chỉ do module Kho quyết định. Khi đơn hàng được xác nhận, module Bán hàng yêu cầu module Kho trừ hàng, thay vì tự sửa số tồn.
Cách chia module trong thực tế
Bắt đầu từ nghiệp vụ, không bắt đầu từ màn hình. Hỏi người làm việc hằng ngày: bước nào do ai chịu trách nhiệm, dữ liệu nào ai là người cuối cùng xác nhận. Ranh giới module thường trùng với ranh giới trách nhiệm trong công ty.
Các nguyên tắc nên giữ:
- Một module, một nhiệm vụ chính, nói được bằng một câu
- Một dữ liệu, một chủ sở hữu
- Module khác muốn dùng dữ liệu thì hỏi qua cổng chung, không đọc chui vào bên trong
- Chia theo nghiệp vụ, không chia theo kỹ thuật (không có module tên "tất cả các nút bấm")
- Báo cáo đọc dữ liệu từ nhiều module nhưng không sửa dữ liệu của module nào
Sai lầm thường gặp
Chia quá nhỏ ngay từ đầu. Chẳng hạn tách riêng module "đơn vị tính" hay "địa chỉ". Quá nhiều mảnh nhỏ làm hệ thống khó hiểu hơn, không dễ hơn.
Chia quá ít. Mọi thứ nằm trong một khối: sửa cách tính giá làm hỏng báo cáo, thêm một trường cho khách hàng làm lỗi kho.
Hai module cùng giữ một dữ liệu. Hai nơi cùng lưu tồn kho là công thức chắc chắn cho số liệu lệch nhau, và nhân viên sẽ mất niềm tin vào hệ thống.
Chia theo sơ đồ tổ chức hiện tại. Công ty đổi cơ cấu thì phần mềm lệch theo. Nên chia theo nghiệp vụ ổn định (bán, kho, tính lương) hơn là theo tên phòng ban.
Quên phân quyền. Module chỉ có ý nghĩa khi đi cùng quy định ai được dùng phần nào. Phân quyền theo vai trò nên được thiết kế từ đầu.
Khi nào chia module chưa cần thiết
Không phải phần mềm nào cũng cần kiến trúc nhiều module. Nếu bạn chỉ cần một công cụ nhỏ cho một việc duy nhất (ví dụ một biểu mẫu thu thập yêu cầu và một danh sách theo dõi), chia module chỉ làm tốn công. Khi phạm vi còn mơ hồ, hãy làm bản đầu nhỏ trước, quan sát cách nhân viên thực sự dùng, rồi mới chốt ranh giới module. Ranh giới sai thường tốn nhiều hơn một ranh giới đến muộn.
Chia module cũng không tự sửa được quy trình lộn xộn. Nếu hai phòng ban chưa thống nhất ai chịu trách nhiệm dữ liệu nào, phần mềm chỉ phản ánh sự lộn xộn đó. Việc làm rõ quy trình trước khi viết mã thường quan trọng hơn chọn công nghệ.
Bước tiếp theo
Nếu bạn đang dùng Excel và muốn biết bắt đầu chia từ đâu, hãy liệt kê các bảng tính bạn dùng hằng ngày: mỗi bảng thường là ứng viên cho một module. Chúng tôi sẽ cùng bạn phân tích quy trình rồi báo giá theo từng giai đoạn. Xem thêm cách chúng tôi triển khai phần mềm quản lý theo yêu cầu và dịch vụ viết phần mềm theo yêu cầu. Nếu băn khoăn nên đặt các module trong một khối hay tách thành nhiều dịch vụ, bài monolith hay microservices cho doanh nghiệp vừa và nhỏ sẽ giúp bạn quyết định.
