.NET 分散式架構開發實戰（一）：專案背景與架構演進啟示

作者以實戰案例開啟系列，記錄從失敗的 SOA 專案 (AIM) 吸取教訓，到主導新專案 (PPM) 設計通用框架的完整思考路徑。

AIM 專案：教科書級的反面教材

• 架構：資料層 → 業務層 → 服務層 → UI 層 (WCF + LINQ to SQL)。
• 問題：
  1. 貧血領域模型：業務層僅做傳遞 (return dal.GetAll())，驗證邏輯散落、程式碼堆疊。
  2. 實體外洩：LINQ 實體 Employee 穿透所有層直達 UI，耦合極高。
  3. 牽一髮動全身：資料庫欄位變更 → 實體變更 → 業務層/服務層/代理/UI 全部要改。
  4. 架構師中途離職，知識斷層，無人能重構。

代碼對比

// DAL
public List GetAllEmplyees() { ... }

// BL - 純轉發
public List GetAllEmplyees() {
  return new EmployeeDAL().GetAllEmplyees();
}

// Service - 純轉發
public List GetAllEmplyees() {
  return new EmployeeBL().GetAllEmplyees();
}

覺醒與行動

作者轉至新專案 PPM (專案進度管理系統)，擔任架構師，決心解決上述問題：

1. 靈活解耦：引入 DTO/VO 隔離實體，業務層聚焦領域邏輯。
2. 通用基礎設施：異常處理、日誌追蹤、快取、驗證機制下沉至基類/切面，業務類「生而強大」。
3. 框架演進策略：在 EMS (員工管理系統) 獨立開發期間，下班時間同步打磨框架雛形，專案結束時框架成熟可用於 PPM。

框架設計哲學

「沒有絕對萬能的技術，架構實現需要在諸多因素間權衡。技術不是用來秀的，而是用來解決問題，這就是技術的價值。」

• 參考 Spring.NET、CSLA.NET、NHibernate 思想，但不盲目引入，依專案領域 (企業管理軟體) 定製。
• 採用領域驅動設計 (DDD) 核心：實體、值物件、聚合根、領域服務、資源庫模式。
• 基礎設施層提供：UnitOfWork、Repository<T>、Specification、Interceptor (AOP)、CacheProvider。

系列規劃

後續文章將逐步展示：

1. 領域模型與資源庫實作
2. 應用服務與 WCF 託管
3. 基礎設施通用組件 (日誌、快取、異常、驗證)
4. UI 層 MVVM 與自動化測試
5. 部署與運維自動化

本系列價值不在於具體專案規模，而在於架構思考與演化過程的完整記錄，供同路人參考、避坑、啟發。

出處：https://www.cnblogs.com/yanyangtian