從同一套型別系統組合出各個領域

主張：領域靠組合來擴展

語意欄位，而非表單元件把意義放進一份全域欄位登錄表裡。這篇文章談的是成長：NT² Vault 如何在不把產品拆分成多個垂直應用程式的情況下，服務眾多領域。

主張是：新領域是組合出來的，不是從零發明的。欄位套件貢獻詞彙。類別範本把這些詞彙排列成結構描述。選用套件按保管箱各自啟用。列層級的功能——到期、密碼健康檢查、共用預設值——跟隨一筆項目目前使用中的欄位集合，而不是一個永久存在的 if (category === "bank") 總機台。

這也是為什麼一座本機優先、零知識的保管箱，今天可以只裝憑證，之後卻能成長到涵蓋文件、銀行明細、SSH 金鑰與醫療卡，卻不會變成一張空白頁，也不會變成一坨特例堆疊的龐然大物。

限制：slug 判斷式會爆炸

最直覺的做法，是靠類別分支來出貨各個垂直領域：

if category == credential → 密碼介面
if category == bank → IBAN 介面
if category == document → 到期日排程

第一天感覺很清楚。隨著目錄成長，它就會失靈。

套件會不斷增生。 光是 IT 領域，就可能包含 API 服務、伺服器、SSH 金鑰、VPN 設定檔與憑證。醫療領域會新增卡片、院所、處方箋。財務領域會新增稅務文件與訂閱項目。每一個只看 slug 判斷的功能，都得再多加一個分支——或者對新套件默默什麼都不做。

逐項目的額外欄位會戳破假象。 一筆文件項目，今年續約時可能需要多一個電話欄位。如果功能只認得「出貨時原樣的文件範本」，那麼這些稀疏的額外欄位，對提醒、搜尋與共用遮罩來說就是隱形的。

平行的型別宇宙就此出現。 每個垂直領域的團隊，都用私有名稱各自出貨自己的「日期」、「證號」、「機密」。你就此失去了前一篇文章所主張的登錄表槓桿。

微應用程式看起來像個逃生口，但其實不是。 沙盒化的介面套件，對於專門工具而言確實是一個合理的產品介面。但它們是欄位型別的錯誤註冊路徑。如果理解一份結構描述得靠載入一個 iframe 應用程式，保管箱核心就不再擁有文件模型的主導權了。

NT² 的限制是：類別標籤負責組織集合；它們不能是功能發現意義的唯一途徑。

設計：套件、範本、使用中欄位

欄位套件＝詞彙

欄位套件是一組帶版本號的語意型別定義。核心套件涵蓋日常機密與備註。領域套件則新增專門詞彙——財務識別碼、基礎架構欄位、醫療卡欄位——同時盡可能重用日期、機密之類的共享型別。

套件是資料。它們會合併成一份登錄表。它們不會各自為「什麼是日期？」出貨一套私有的執行環境。

類別範本＝結構描述

一份類別範本，會挑出一組有序的欄位型別、標籤與配置選項（是否必填、共用預設值、顯示提示）。官方套件會出貨現成的範本：憑證與備註是核心內建類別；銀行、文件、加密貨幣、IT、醫療、零售等，則是可選用的啟用項目。

啟用一個套件，比較接近安裝一份結構描述套件，而不是安裝一個新產品。保管箱始終是同一個應用程式，只是集合清單變多了。

不需要新型別的 L0／L1／L2

客製化分成幾個層級，但仍然都在登錄表之內：

L2 讓一列可以多一個聯絡欄位，而不必發明新類別或新欄位型別。一列的使用中欄位集合，就是範本配置聯集 L2 額外欄位。

功能讀取使用中欄位集合

flowchart TB
  Packs[欄位套件] --> Reg[合併後的登錄表]
  Reg --> Tpl[類別範本]
  Tpl --> Active[使用中欄位集合]
  L2[逐項目額外欄位] --> Active
  Active --> Edit[編輯表單]
  Active --> View[檢視外觀]
  Active --> Present[呈現／共用遮罩]
  Active --> Feat[到期、健康檢查、特徵組合]

到期提醒在乎的是：這一列上是否存在一個已填值的 expiryDate（或等效語意）欄位——而不是這個 slug 字串是否等於 document。密碼健康檢查在乎的是：這一列上是否存在一個密碼形狀的欄位——就算它的類別是「API 服務」範本而非傳統的憑證類別也一樣。共用與呈現流程，也是從同一套集合中讀取配置與型別預設值。

特徵組合（多欄位指紋）的運作方式也一樣：「這些銀行欄位夠不夠多，足以被當成一份銀行摘要」是一個欄位集合的問題，不是一個 slug 的問題。

同步與備份對領域一無所知

類別 slug 與封裝後的內容，都以資料的形式同步。邊緣不需要一套醫療本體論。組合是客戶端的事；零知識是邊緣的事。這條分界線是承重結構，不能妥協。

取捨：啟用套件，而不是出貨垂直應用程式

組合要求使用者（以及產品本身）主動啟用自己需要的領域。一座全新的保管箱，不會預先塞滿每個產業的範本。範本作者也必須重用既有型別，而不是鑄造長得很像的替身。

不這麼做，代價會更糟：一整座迷你保管箱的應用程式商店，每一座都有自己的匯出格式；或是一份被類別分支淹沒的單一程式碼庫。

我們拒絕什麼

我們拒絕把類別 slug 當成長期的功能開關。 slug 用來組織清單與預設值。它不能取代讀取使用中欄位集合。

我們拒絕把微應用程式當成欄位註冊的路徑。 專門介面可以出現在沙盒裡；語意型別仍然只能透過登錄表與範本套件進入系統。

我們拒絕為每個垂直領域出貨一個新應用程式。 銀行、文件、SSH 金鑰是套件與範本——不是各有各的信任故事的獨立產品。

我們拒絕靠把「密碼」拆成五個私有機密欄位來擴展領域。 重用目錄；只有在真正出現新概念時，才審慎擴充它。

一份目錄，多個集合

這個部落格上的家庭故事，常常把結構當成一種紓解來談：桌面上的那份試算表與已經本機優先，卻少了結構。組合，正是這種紓解得以橫跨各個領域、卻不會把保管箱變成 Notion 的工程理由。

接下來：可搜尋的中繼資料，封裝後的欄位值——說明清單／搜尋如何保持好用，同時敏感欄位以封裝後的索引形式離開記憶體。之後，四個介面，一組欄位則會收束本系列的第一條主線。

關於這些欄位周圍的可攜密文，可參考CBF：結構化欄位離開記憶體的方式。歡迎試用 NT² Vault，或閱讀 nt2.me。