上一篇《企業 SOA 設計(1)–ESB 設計》中，寫到我們的 SOA 設計分為兩個層面來進行：一個是系統間的 SOA 設計，主要通過 ESB 來完成；另一方面則是單個應用系統內部的 SOA 設計，本篇將會就后者進行詳細說明。
平台整體結構
在產品開發過程中，為了達到業務級別的較大粒度重用，我們需要把縱向把業務進行拆分，以業務組件的形式進行開發，並最終把多個開發完成的業務組件進行組合，形成最終的軟件產品。
按照組件化開發的產品，是基於一個公共的產品開發平台來建立的。由平台來提供所有的底層設施。平台包括技術平台和業務平台兩個層面。在技術層面上，平台提供了一系列的類庫、框架、組件、工具，以及為業務組件化提供相應的技術支撐。在業務層面上，業務平台中積累了大量的封裝完善的業務組件，以及一些常用的業務控件，以供開發新產品時進行選配。同時，平台還為整個軟件過程提供一系列的其它支持，例如工具、設計器、管理界面等。
下圖，是平台的整體結構圖：
圖中羅列了大部分的關鍵組成部分，細節本篇不述。
組件集成平台
對於一個獨立的業務，我們可以將其封裝為一個獨立的業務組件，並最終放到組件庫中。業務組件之間，則以服務、事件兩種形式進行交互。要支持這種模式的交互，技術平台還需要提供幾個技術框架：插件平台、服務容器、事件總線。
下圖是組件集成架構：
- 技術平台提供事件總線、輕量級服務總線。
- 組件內部以領域驅動的模式開發，以領域實體框架作為基礎框架。組件內、組件間，也都是面向領域實體來進行交互。
- 組件向外部的其它組件提供組件事件、組件服務。外部組件也只能直接調用組件提供的服務，或者監聽組件的事件。
- 組件還提供了一些可重用的 UI、一些可直接使用的分布式服務。
- 整個應用系統在組合多個業務組件后，再開發一些特定的功能、UI 就可以完成一個完整的系統了。
產品構成
下圖是一個完整產品的組件構成圖：
由於我們的產品開發平台必須要支持 721 客戶化定制，所以同一個業務組件還對應不同的業務通用級別進行划分：Organization Common 表示組織架構組件最通用的部分，Org Part1 表示組織架構組件的可選包。而 Customiztion 則可以對引用的業務組件做深入的定制和擴展，而不需修改引用組件的代碼。
可以看到，對於整個產品來說，在引用了業務組件庫中的一些業務組件后，就可以組成了產品的基礎功能。Customer App Component 中是應用系統在組件的功能基礎上需要再做的工作：完成產品的額外功能，並通過平台接口為一些組件做相關定制。
組件內部架構
對於單個的業務組件，其內部的架構依然采用領域驅動的分層架構：
圖雖大，但並不復雜，就是領域驅動的經典分層：Distribute（DTO 接口層）、Application（應用層/領域邏輯層）、Repository（倉庫）、Domain（領域實體）。
重點在於 Domain 包，它不但包括領域實體，還包括了組件事件、組件服務接口，這些都是領域的核心。
位於底層的技術平台，提供一系列支持：IOC/AOP、屬性擴展框架、領域實體框架、721定制化框架、數據庫生成框架等……
結尾
其實，組件化架構設計中，最為復雜是分析出一個封裝完好的組件，所要面向的使用者是哪些，這些使用者分別對組件有哪些需求，而這個架構如何滿足這一系列需求。例如，我們在設計過程中，對這些方面進行了分析：組件自身的發展需求、組件中各組成部分的可擴展性、組件間的交互需求、系統集成需求、項目組定制化需求、系統外交互需求、易用性。
歡迎感興趣的朋友交流。