平台整體結構
在産品開發過程中，為了達到業務級别的較大粒度重用，我們需要把縱向把業務進行拆分，以業務元件的形式進行開發，并最終把多個開發完成的業務元件進行組合，形成最終的軟體産品。
按照元件化開發的産品，是基于一個公共的産品開發平台來建立的。由平台來提供所有的底層設施。平台包括技術平台和業務平台兩個層面。在技術層面上，平台提供了一系列的類庫、架構、元件、工具，以及為業務元件化提供相應的技術支撐。在業務層面上，業務平台中積累了大量的封裝完善的業務元件，以及一些常用的業務控件，以供開發新産品時進行選配。同時，平台還為整個軟體過程提供一系列的其它支援，例如工具、設計器、管理界面等。
下圖，是平台的整體結構圖：
圖中羅列了大部分的關鍵組成部分，細節本篇不述。
元件內建平台
對于一個獨立的業務，我們可以将其封裝為一個獨立的業務元件，并最終放到元件庫中。業務元件之間，則以服務、事件兩種形式進行互動。要支援這種模式的互動，技術平台還需要提供幾個技術架構：插件平台、服務容器、事件總線。
下圖是元件內建架構：
技術平台提供事件總線、輕量級服務總線。
元件内部以領域驅動的模式開發，以領域實體架構作為基礎架構。元件内、元件間，也都是面向領域實體來進行互動。
元件向外部的其它元件提供元件事件、元件服務。外部元件也隻能直接調用元件提供的服務，或者監聽元件的事件。
元件還提供了一些可重用的 ui、一些可直接使用的分布式服務。
整個應用系統在組合多個業務元件後，再開發一些特定的功能、ui 就可以完成一個完整的系統了。
産品構成
下圖是一個完整産品的元件構成圖：
由于我們的産品開發平台必須要支援 721 客戶化定制，是以同一個業務元件還對應不同的業務通用級别進行劃分：organization common 表示組織架構元件最通用的部分，org part1 表示組織架構元件的可選包。而 customiztion 則可以對引用的業務元件做深入的定制和擴充，而不需修改引用元件的代碼。
可以看到，對于整個産品來說，在引用了業務元件庫中的一些業務元件後，就可以組成了産品的基礎功能。customer app component 中是應用系統在元件的功能基礎上需要再做的工作：完成産品的額外功能，并通過平台接口為一些元件做相關定制。
元件内部架構
對于單個的業務元件，其内部的架構依然采用領域驅動的分層架構：
圖雖大，但并不複雜，就是領域驅動的經典分層：distribute（dto 接口層）、application（應用層/領域邏輯層）、repository（倉庫）、domain（領域實體）。
重點在于 domain 包，它不但包括領域實體，還包括了元件事件、元件服務接口，這些都是領域的核心。
位于底層的技術平台，提供一系列支援：ioc/aop、屬性擴充架構、領域實體架構、721定制化架構、資料庫生成架構等……
結尾
其實，元件化架構設計中，最為複雜是分析出一個封裝完好的元件，所要面向的使用者是哪些，這些使用者分别對元件有哪些需求，而這個架構如何滿足這一系列需求。例如，我們在設計過程中，對這些方面進行了分析：元件自身的發展需求、元件中各組成部分的可擴充性、元件間的互動需求、系統內建需求、項目組定制化需求、系統外互動需求、易用性。
歡迎感興趣的朋友交流。