技術層面：分解與集成的手段
基礎手段：語言與框架
- 語言即強框架：OO 語言提供繼承（邏輯分層集成）、介面隔離（外觀與實現分離）、AOP/屬性（流程邏輯分解與代碼生成集成）。
- 框架即弱語言：Spring 容器管理對象關聯、OSGi/ESB 模塊關聯、Spring Web Flow/jBPM 流程邏輯分解、動態代理 Exporter 模式跨系統類型集成、模式封裝（API/Web Service/RMI/Command/Event）。
開發方式三元論
| 維度 | 程序式編程 | 聲明式編程 | 產生式編程 |
|---|
| 手段 | 編碼 | 解析 | 生成 |
| 代表 | Java/C# | ANT/XML 配置 | AOP/DSL/Drools |
| 性質 | 聚合 | 聲明 | 組合 |
| 粒度 | 細 | 粗 | 相對細 |
| 方向 | 自底向上 | 自上向下 | 自底向上 |
元編程最高層次是語言級，代碼生成是最低級。代碼生成若產出功能性代碼（DSL）優於結構性代碼（同步維護問題）。
核心問題四大支柱
1. 領域化：領域建模
- 對象抽象分解/集成、依賴分解/集成（模塊內外）、流程分解/集成（頁面流/工作流/計算流）、進程邊界（請求重定向/持久化）
- 中等項目 50-100 個領域對象
2. 組件化
- OSGi (JSR 291) / SCA 解決組件服務依賴與熱替換
- 邏輯分層（核心層/國家層/公司層）：OSGi + Spring 實現靜態/動態差異性替換
- 邊界保護：代碼提交/發布時靜態檢查 或 OSGi 運行時隔離
3. 產品化：定制化與升級
- 邏輯替換兩路徑：基於介面（靜態 Override/配置、動態 Condition Service Locator/Extension Point）vs 基於繼承（源碼修改、AspectJ 編譯期織入、類加載優先級）
- 升級：增量升級、有限降級、定制化產品兼容衝突檢測
4. 平台化：基礎設施與業務支撐
- 基礎設施選型：成熟度、效能、穩定性、環境適應性、開發/維護/測試/培訓/招聘成本
- 集成策略：無標準不封裝（畫蛇添足），有標準不封裝（多此一舉），框架方式屏蔽侵入性
- 業務支撐三位一體：DI + AOP + 元數據 → POJO 化，每個對象做且只做一件事
- 元數據視角：應用層（業務/技術含義）、技術分析（文檔/編譯/運行期）、物理分析。目的：業務動態能力 + 簡化開發。避免為技術過度開發元數據導致隨業務演進被拋棄。
應用問題：集成能力決定分解粒度
- 依賴管理：業務對象依賴 + 環境依賴 → Spring DI 解決對象依賴、動態代理封裝環境依賴、ORM 區分領域/業務邏輯、AOP 處理橫切關注點
- 數據對象 VO：為集成而生。隨框架路徑訪問能力（EL）、事務邊界管理增強，VO 逐漸失去存在意義。Data Tree + EL 扁平化訪問大幅提效。
- 事件機制：鬆耦合擴展基石，可擴展同步/異步、事務隔離控制
- 組件設計：API（客戶端）+ SPI（服務端/回調），單向依賴降低成本，平級組件嚴守邊界。介面變更協作機制：共同負責、假實現、重構補全測試
- 膠水層：適配器（業務/技術）+ 開發模式（ORM/有狀態 Web 框架/元數據識別）盡量自動化
- 集成階段：設計時（手工碼）、編譯/加載時（配置）、運行時（元數據解析）
部署方式
- 本地部署
- 分布式部署：前後端分離（傳統 EJB，面臨分布式調用/事務/上下文傳遞成本）或 Portal 技術
設計問題：文檔與代碼融合
Color UML 輔助閱讀。新方式：代碼記錄分析設計成果 → 形成穩定抽象層代碼 → 實現繼承/適配抽象層。知識層做正確的事，操作層把事做高效。
架構展示：RUP 4+1 視圖 + 擴展視圖
| 核心視圖 | 關注點 | 映射產物 |
|---|
| 邏輯視圖 | 功能、輔助模塊 | 業務組件、功能包、技術工件、依賴關係 |
| 開發視圖 | 程序包、第三方 SDK、中間件 | 具體 SDK/框架、依賴關係（力求與邏輯視圖一一對應） |
| 處理視圖 | 進程/線程/對象、併發/同步/通信 | 狀態圖/活動圖 |
| 物理視圖 | 部署拓撲、可靠性/擴展性 | 組件圖、部署說明圖 |
擴展視圖：非功能視圖（技術指標）、基礎設施視圖、數據視圖（DBA/運維）。必須說明原則、約束、技術選型分析。
