# FR-080 判準（開工前寫定，全程只用這一組）

## 問題一：哪些套件該合併（套件疆界）

一支套件 = 一個「能力」。兩支要不要合併，只問三個問題，順序固定：

C1 資料同生共死？（D17 律①）
   - 兩邊的表想建 FK、同一交易寫兩邊、一邊沒另一邊沒意義 → 是同一件事，合。
   - 只存對方 id 的軟參照 → 不算。

C2 換個產品，會不會一起被拿走？
   - 一個跟稽核無關的新產品要裝 A，一定也要裝 B（或反之）→ 合。
   - A 可以單獨用、B 也可以單獨用 → 不合，即使同族。

C3 同一個人養？（發版節奏／操作者）
   - 兩邊從未獨立演化、同批 bump、改一邊必改另一邊 → 支持合。
   - 這是輔助條件，C1/C2 都不成立時 C3 單獨不能合。

反向條件（任一成立就不合，即使 C1–C3 都像）：
   R1 合併後會讓一堆本來不依賴 X 的套件被迫依賴 X（合併對象是「被很多人依賴的供應者」）
   R2 合併後套件會變成「開機時做很多不相干事」的雜物袋（決策者對 system-infra 的定義是「系統開起來一定要有」，不是「雜物」）

決策者已表態（輸入，不重議）：
   - asset：device + information-system 合
   - flow-engine 不併 task-platform
   - notification 獨立（會持續擴充）
   - system-infra = 「系統開起來一定要有的基本功能」

## 問題二：朝微服務怎麼走（部署疆界）

「套件疆界」與「部署疆界」是兩件事，用兩個詞：
   - 合併/不動 → 講套件
   - 同進程/分開部署 → 講部署

一支套件能不能分開部署，只問：
   S1 它跟宿主之間的資料交換能不能全部變成「網路呼叫 + 軟參照」？（有跨界 FK 就不行，先改軟參照）
   S2 它有沒有獨立的生命週期理由：不同的擴縮型態（CPU 重／I/O 重／長時間工作）、不同的發版節奏、不同的安全邊界、不同的操作者
   S3 分開之後，宿主的哪些聚合查詢會斷？（骨幹 readmodel 清單）斷的能不能改成 API 拼裝或 CQRS 讀模型？

沒有 S2 理由的，不分開部署——微服務的成本（網路、一致性、部署、觀測）要有理由才付。

## 產出形式

- 25 支逐支：結論（合併進 X／不動／退役）+ 一句內容級理由（引 C1–C3 / R1–R2）
- 部署：哪些「可分開部署」、哪些「預設分開部署」、每個分開的理由（引 S1–S3）、要補什麼
- 白話、詳細，給決策者討論用