> ## Documentation Index
> Fetch the complete documentation index at: https://learn.cleeksy.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Ranh giới ứng dụng

> Quy tắc tách ứng dụng (app) và giữ cùng app theo ranh giới vận hành.

Trang này cung cấp các quy tắc thực dụng để quyết định **ranh giới app**: giữ trong một app hay tách thành nhiều app và kết nối với nhau.

## 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”

Liên quan:

* [Chọn Value Slice theo SMALL](/foundations/value-slices-small)
* [Ownership & chia sẻ dữ liệu (Data ownership & sharing)](/foundations/data-ownership-sharing)

## 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

**Nên giữ** khi:

* 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)

**Nên giữ** khi:

* 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

Tham khảo: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)

## Cây quyết định nhanh

<Steps>
  <Step title="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.
  </Step>

  <Step title="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.
  </Step>

  <Step title="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).
  </Step>

  <Step title="Bước 4 — Kết nối dữ liệu theo hướng nào là hợp lý?">
    Ưu tiên thiết kế một app “nguồn” publish và app khác consume để giảm coupling.
  </Step>
</Steps>

## 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

Xem chi tiết: [Chia sẻ dữ liệu (Publish/Consume)](/build-apps/integrations/publish-consume-overview)

## 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)

Kết nối:

* 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

Khi gặp các dấu hiệu này, nên quay lại:

* 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)](/foundations/data-ownership-sharing)
* Đặt controls đúng chỗ: [Controls trong hệ thống (workflow vs validation vs roles)](/foundations/controls-in-system)
* Tổ chức delivery theo vòng lặp: [SDD là gì](/sdd/overview)