JCConf Taiwan 2026 — 當 1+1 不再永遠等於 2：LLM 在領域模型中的能力與邊界

1.1 會議現場的核心方法論全景

在 Kim Kao 的議程演講中，為了解決 LLM 介入業務系統時「機率推論破壞確定性規則」的核心矛盾，著重於以領域驅動設計（DDD）的引導工作坊與規約工程作為概念核心。

下圖前半部（①～⑤）為演講所梳理之核心收斂鏈，後半部（⑥～⑦）則為進一步結合代碼圖譜之工程落地延伸：

flowchart TD
    subgraph Speaker_Concept ["講者核心概念鏈 (DDD & Spec Workshops)"]
        A["① Domain Storytelling<br>【領域故事敘說】<br>角色、行動、工作物件"] -->|萃取概念與語義| B["② Ontology Modeling<br>【業務本體建模】<br>實體、狀態、關係、不變量"]
        B -->|動態時間軸展開| C["③ Event Storming<br>【事件風暴】<br>挖掘 Domain Events、Commands、Policies"]
        C -->|具體化規則邊界| D["④ Example Mapping<br>【實例對映】<br>規則、邊界案例、正反實例"]
        D -->|形式化契約| E["⑤ Gherkin Spec<br>【可執行規約】<br>Given - When - Then"]
    end

    subgraph Engineering_Extension ["工程落地超譯與延伸 (Dual-Graph & Execution)"]
        E -->|攜帶領域實體名詞| F["⑥ CodeGraph Grounding<br>【代碼拓撲錨定】<br>呼叫鏈、路由、影響半徑"]
        F -->|精確上下文約束| G["⑦ Agentic Execution<br>【Agent 實作與防禦】<br>測試驗證與持續閉環"]
    end

1.2 五階推進詳解：如何將「業務直覺」編譯為「Agent 憲法」

1.3 傳統 AI Coding 的「業務語義斷裂」痛點

• 名詞分裂（Semantic Drift）：同一業務概念在不同模組、不同 Agent 輪次被隨意命名（如 User vs. Account vs. Customer）。
• 規則黑盒（Hidden Invariants）：Agent 可以產生表面語法完全正確的程式碼，但底層違反跨模組業務限制（例如：尚未完成 KYC 的帳戶直接觸發放款）。
• 狀態機穿透：合法狀態轉移被跳過，甚至繞過 Audit Log 與事件廣播直接改動資料庫。

1.4 本體閉環工程（Ontology-Grounded Loop）的三層架構

借鑑積墨 AI（Jimo Studio）文章中所梳理的三層語義結構，將業務本體映射為可執行的軟體系統：

┌─────────────────────────────────────────────────────────────┐
│ 1. Ontology Knowledge（描述性語義）                         │
│    對象、狀態、關係、規則、權限、例外、不變條件             │
└──────────────────────────────┬──────────────────────────────┘
                               │ 規格編譯 (Event Storming + Example Mapping)
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ 2. Ontology-grounded Spec（規格橋樑 / Gherkin）              │
│    狀態轉移圖、API 契約、Given-When-Then 驗收測試、領域事件 │
└──────────────────────────────┬──────────────────────────────┘
                               │ 代碼與世界生成 (CodeGraph + Harness)
                               ▼
┌─────────────────────────────────────────────────────────────┐
│ 3. Ontological Twin（操作性語義與數位孿生）                 │
│    可執行、可模擬、可斷言業務違規的操作世界                 │
└─────────────────────────────────────────────────────────────┘

1.5 概念辨析矩陣：Ontology vs. DDD vs. Knowledge Graph

1.6 核心工程載體：領域契約本體表（The Domain Contract Table）

#### ① 本體表的核心 Schema 欄位推導

這張表將軟體架構的「實體骨架」與領域模型的「動態規則」凝練在一起，定義了六大剛性欄位：

#### ② 機器可讀格式定義（domain-ontology.yaml）

這張本體表在專案中可以直接落實為可執行的元數據設定檔（或專用 DSL）：

# docs/domain/ontology-table.yaml
domain: SubscriptionBilling
package: com.company.billing.subscription.domain.model

entities:
  - class: Subscription
    state_field: status
    states: [DRAFT, ACTIVE, SUSPENDED, CANCELLED]
    operations:
      - method: upgradePlan
        parameters:
          - name: targetPlan
            type: com.company.billing.plan.domain.PlanId
          - name: operatorId
            type: com.company.billing.iam.domain.UserId
        return: io.vavr.control.Either<SubscriptionError, SubscriptionUpgraded>
        preconditions:
          - "this.status == SubscriptionStatus.ACTIVE"
          - "targetPlan != this.currentPlan"
        postconditions:
          - "this.currentPlan == targetPlan"
          - "emits SubscriptionUpgraded(this.id, targetPlan, operatorId)"
        forbidden_transitions:
          - from: CANCELLED
            reason: "已取消的訂閱不可執行任何升級操作"

1.7 受控實作與確定性驗證閉環（Deterministic Execution & Dual Verification）

當有了「領域契約本體表」，AI Coding 的工作流程由「放任生成」轉變為「受控施工」，並具備客觀的自動化驗收依據：

flowchart TD
    T["① Ontology 契約表<br>Package, Class, Signature, Rules"] -->|擷取對應行作為 Context| P["② Prompt Context Injection<br>給予 Agent 剛性約束邊界"]
    CG["③ CodeGraph 輔助拓撲<br>定位既有呼叫者、依賴項與測試"] --> P
    P --> AGENT["④ AI Coding Agent<br>在狹窄通道內施工實作代碼"]
    AGENT --> CODE["⑤ 產出實體代碼"]
    
    subgraph Dual_Verify ["雙軌客觀驗證閉環 Dual Verification"]
        direction TB
        CODE --> V1["★ 軌道一：靜態契約驗收 Static Compliance<br>AST / ArchUnit / 反射比對<br>驗證 Package, Class, 參數型別與回傳值是否 100% 吻合"]
        CODE --> V2["★ 軌道二：動態語義驗收 Dynamic Compliance<br>Gherkin 驗收測試 + Invariant 斷言<br>驗證狀態轉移與不變量是否被破壞"]
    end

    V1 -->|未吻合| FAIL["直接駁回修正"]
    V2 -->|未通過| FAIL
    FAIL --> AGENT
    V1 -->|通過| PASS["PR 交付"]
    V2 -->|通過| PASS

1. Context 注入非隨機：

• 實作前，Prompt 不直接給模糊需求，而是精準注入本體表中該操作的完整定義行。
• CodeGraph 的輔助定位：Agent 拿著表中的 Subscription.upgradePlan 呼叫 codegraph explore，找出當前代碼庫中是誰在呼叫它、需要注入哪些 Repository 與 EventPublisher，省去檔案漫遊。

1. 雙軌自動化驗收（Deterministic Verification）：

• 軌道一：靜態結構驗收（Static Compliance）：
• 撰寫輕量級的 ArchUnit 測試或 AST 檢查腳本，直接讀取 ontology-table.yaml，比對生成的 Java/Kotlin 代碼：
• 是否在正確的 package？
• 類別名稱是否相符？
• 方法參數型別與回傳型別是否 100% 嚴格一致？
• 任何型別或命名偏差在編譯與靜態檢查階段直接報錯，不需要人工肉眼審查。
• 軌道二：動態邏輯驗收（Dynamic Compliance）：
• 執行根據本體表中 preconditions 與 forbidden_transitions 生成的 Gherkin 測試，確認違反業務規則時必定正確拋出例外或回傳錯誤。

flowchart TD
    subgraph Strategy ["1. 戰略治理層"]
        WM["Wardley Mapping<br>組件演進與邊界決策"]
    end

    subgraph Semantics ["2. 人機語義與規約層"]
        DDD["敏捷與 DDD 工藝流<br>Storytelling ➔ Event Storming ➔ Example Mapping"]
        ONTO["企業數位孿生流<br>Palantir AIP Ontology ➔ OOLE 操作世界"]
    end

    subgraph Code_Bridge ["3. 代碼實現與邊界防禦層"]
        TYPE["型別系統與內部品質流<br>Type-Driven ➔ Parse, don't validate"]
        TOPO["代碼拓撲與上下文工程流<br>CodeGraph ➔ LSP for Agent ➔ 影響半徑"]
    end

    Strategy --> Semantics
    Semantics --> Code_Bridge

演進階段：     Genesis ──────> Custom-Built ──────> Product/Rental ──────> Commodity/Utility
業務定位：   [探索性新業務]    [核心競爭力領域模型]     [標準商用產品]          [基礎通用設施]
                   │                  │                   │                     │
AI 策略：     Vibe Coding       ★ 完整五階收斂鏈        直接採用現成模組        LLM 直接生成
             快速驗證原型       DDD + Ontology-lite     (SaaS / 開源庫)        或使用標準 API
                               + CodeGraph + Harness

┌──────────────────────────────────────────────────────────────┐
│                    Ontology（業務語義層）                    │
│   定義「為什麼」與「能否做」：業務實體、權限規則、狀態轉移限制 │
└──────────────────────────────▲───────────────────────────────┘
                               │ 映射與雙向約束
┌──────────────────────────────▼───────────────────────────────┐
│                   CodeGraph（代碼拓撲層）                    │
│   掌握「在哪裡」與「怎麼做」：檔案路徑、符號位置、精確呼叫鏈   │
└──────────────────────────────────────────────────────────────┘

flowchart TD
    subgraph S1 ["階段一：頂層語義與規約 Top-Down"]
        O["Ontology-lite 規格定義"] --> S["Ontology-grounded Spec"]
        S -->|提供領域符號名詞| CG_IN["CodeGraph 符號定位"]
    end

    subgraph S2 ["階段二：精確拓撲檢索 Grounding"]
        CG_IN -->|codegraph_explore| CTX["Surgical Context 呼叫鏈與原始碼"]
    end

    subgraph S3 ["階段三：Agent 實作與防禦 Execution"]
        CTX --> AGENT["Coding Agent 實作代碼"]
        AGENT --> CODE["本地代碼庫變更"]
    end

    subgraph S4 ["階段四：驗證與影響分析 Verification"]
        CODE -->|檔案異動| SYNC["CodeGraph 自動增量同步"]
        CODE -->|執行測試| TEST{"業務約束與 Invariants 通過？"}
        SYNC -->|codegraph affected| IMPACT["評估變更影響半徑 Blast Radius"]
        TEST -->|失敗| AGENT
        TEST -->|通過| PASS["PR 交付"]
    end

# specs/features/subscription_upgrade.feature
Feature: 訂閱升級與領域事件廣播
  Scenario: 活躍訂閱者成功升級方案
    Given 客戶持有狀態為 "ACTIVE" 的訂閱 "sub-101"
    When 客戶請求升級為 "PRO_MONTHLY" 方案
    Then 訂閱方案應變更為 "PRO_MONTHLY"
    And 系統必須發布 "SubscriptionUpgraded" 領域事件

  Scenario: 已取消的訂閱禁止升級（違反業務不變量）
    Given 客戶持有狀態為 "CANCELLED" 的訂閱 "sub-202"
    When 客戶請求升級為 "PRO_MONTHLY" 方案
    Then 請求應被拒絕並拋出 "SubscriptionCancelledException"
    And 系統不得發布任何領域事件

# Agent 呼叫 CodeGraph MCP 工具
codegraph_explore "Subscription upgrade endpoint and domain state machine"

   git diff --name-only | codegraph affected --stdin

your-project/
├── .codegraph/                  # CodeGraph 原生資料庫與本機快取
├── docs/
│   └── domain/
│       ├── ontology.yaml        # 業務本體定義（實體、關係、狀態、不變量）
│       ├── glossary.md          # 統一領域詞彙（Ubiquitous Language）
│       └── state-machines/      # 狀態機與合法轉移規範
├── specs/                       # 基於本體編譯出的具體功能規格
└── src/                         # 實體業務代碼