Mục tiêu
- Giảm rủi ro mega-app (quá lớn, khó thay đổi, khó vận hành)
- Làm rõ ownership (ai chịu trách nhiệm dữ liệu và quy trình)
- Thiết kế ranh giới giúp mở rộng theo thời gian mà không “đập đi làm lại”
App boundary là gì?
App boundary là ranh giới thiết kế để xác định:- App này sở hữu dữ liệu nào (source of truth)
- App này chịu trách nhiệm quy trình nào
- Người dùng nào sử dụng app này như “màn hình làm việc chính”
- App khác sẽ consume dữ liệu như thế nào (khi cần)
Quy tắc tách/ghép app (decision rules)
1) Tách theo ownership dữ liệu (nguồn dữ liệu)
Nên tách khi:- Có nhiều bộ phận cùng “sở hữu” một tập dữ liệu và không thống nhất được nguồn
- Một tập dữ liệu cần quản trị chặt (chuẩn hoá, audit, quyền sửa) trong khi phần còn lại linh hoạt
- Một nhóm chịu trách nhiệm rõ ràng cho dữ liệu và quy trình, vòng đời record nằm trong cùng nhóm
2) Tách theo nhịp thay đổi (change cadence)
Nên tách khi:- Một phần thay đổi thường xuyên (UI/luồng thao tác), phần còn lại ổn định (master/reference)
- Tốc độ thay đổi khác nhau gây “kẹt” release nếu nằm chung
3) Tách theo độ phức tạp workflow
Nên tách khi:- Workflow có quá nhiều nhánh/ngoại lệ khác nhau theo phòng ban
- Một workflow đang cố gắng “ôm” nhiều quy trình khác nhau (mỗi bộ phận một kiểu)
- Có một luồng chính rõ ràng, số trạng thái và nhánh còn kiểm soát được
4) Tách theo đối tượng người dùng và UI
Nên tách khi:- Hai nhóm người dùng có cách làm việc khác nhau hoàn toàn (màn hình, thao tác, ngôn ngữ nghiệp vụ)
- Một nhóm chỉ cần “theo dõi”, nhóm khác cần “xử lý” với công cụ khác
5) Tách theo biên giới rủi ro và kiểm soát (policy boundary)
Nên tách khi:- Một phần cần kiểm soát nghiêm (duyệt, phân quyền trường, tuân thủ), phần khác mang tính cộng tác nhẹ
- Chính sách truy cập khác nhau đến mức “một app” trở nên khó cấu hình
Cây quyết định nhanh
Bước 1 — App có một ownership rõ ràng không?
Nếu không rõ ownership dữ liệu hoặc quy trình: cân nhắc tách theo đơn vị chịu trách nhiệm.
Bước 2 — Workflow có còn kiểm soát được không?
Nếu số nhánh và ngoại lệ tăng nhanh: tách theo luồng/nhóm người dùng.
Bước 3 — Người dùng có cần hai cách làm việc khác nhau không?
Nếu UI/nhu cầu thao tác khác biệt lớn: tách app (hoặc tách experience).
Cách kết nối sau khi tách app (nguyên tắc tối thiểu)
- Chỉ định rõ “app nguồn” và dữ liệu được publish
- App còn lại consume theo nhu cầu thao tác (không sao chép tuỳ tiện)
- Hạn chế two-way nếu chưa có quy tắc đồng bộ rõ ràng
Ví dụ nhanh: Purchase Request và Procurement
Một cách tách phổ biến:- App A: Purchase Request Sở hữu dữ liệu yêu cầu mua (tạo, phê duyệt, trạng thái yêu cầu)
- App B: Procurement Sở hữu dữ liệu xử lý mua sắm (nhà cung cấp, PO, trạng thái đặt hàng/nhận hàng)
- App Procurement consume thông tin yêu cầu đã phê duyệt
- App Purchase Request consume trạng thái xử lý (read-only) để người yêu cầu theo dõi
Dấu hiệu ranh giới đang sai
- Một app có quá nhiều entity “không liên quan” đến nhau
- Workflow thay đổi một phần kéo theo sửa nhiều chỗ khác
- Permissions trở nên rối và khó giải thích
- Không ai dám chỉnh vì sợ “vỡ” hệ thống
- SMALL để thu hẹp phạm vi
- Ownership để tách nguồn dữ liệu
- Controls để giảm logic phân tán
Bước tiếp theo
- Quyết định chia sẻ dữ liệu: Ownership & chia sẻ dữ liệu (Data ownership & sharing)
- Đặt controls đúng chỗ: Controls trong hệ thống (workflow vs validation vs roles)
- Tổ chức delivery theo vòng lặp: SDD là gì