關於Nature框架的架構

該框架致力於創建爲一套DDD的分佈式框架

首先，這是一套DDD的框架，包含了其中的要素

其次，這是一套分佈式框架，即，DDD的運做須要創建在分佈式的基礎之上。

另外，咱們但願該框架足夠開發，靈活，穩定，高效，可伸縮

該框架的總體架構暫定以下圖：

該框架的基本設想以下：

咱們將處理應用業務的部分稱爲內部，與之相對的，對應用外部提供的接口稱之爲外部接口，與客戶端的地位等同，客戶端也可創建在對外接口之上。

話說，通常來講，客戶端應該只能創建在對外接口之上，我是贊同此觀點的。可是，我爲何不這麼作呢，由於不肯定，我不肯定個人對外接口可以知足一切服務總線提供的功能提供給客戶端，

在這個不肯定之上，我保留這個對外的口子，不過仍是推薦獎客戶端創建在對外接口之上。

內部的服務則是爲了支撐起整個應用體系，爲此，這裏引入了企業服務總線（ESB）這個東西，以接觸子系統之間的深度耦合，以指望該結構能夠總體應用的可伸縮性上起到做用。

而搭載在總線上的內容，咱們稱之爲節點。總線，和節點相互交織成網狀結構，對外提供應用功能。

每一個節點老是會被一層咱們稱之爲防腐層的層次包圍，該層次，咱們但願它能夠儘可能的薄，它的做用爲對外通信，內容轉換，使外部的數據結構不會腐蝕領域中的模型。

防腐層內部包裹的則爲領域，領域這裏則是經典的ddd中所提到的內容了，咱們這裏假設其主要有聚合跟，實體，值對象，領域事件，領域服務構成，另外極可能還須要倉儲及查詢的支持。

節點和節點之間的通信，咱們僅假設了兩種方式，即命令與事件，值得注意的是，這裏的事件和領域事件並不能夠劃等號，由於他們所在工做的層次不一樣。

接下來就是大量的基礎設施了，他們是爲了支撐這個架構而存在的，或許還會提供些許便利的功能。

對了，該框架目前依賴於這樣兩個框架：

structuremap 2.6.1.0     該框架提供IoC的功能，沒有封裝，與框架深度耦合，在短期內也沒有對該模塊進行封裝的打算

Shuttle 該框架的總線支持，由其提供。

log4net     該框架提供了日誌基礎功能。

來自爲知筆記(Wiz)