工做日誌20150202

在過去，這裏的設定是這樣的

領域事件由領域事件接口定義，反射獲取映射，同步分發執行。

工做單元（UnitOfWork）負責事務

實體與值對象分別有一個空的基類，用以應對個字可能的共性。

聚合根由接口定義，其中最主要的是，其必定會有一個ID，而這個類型被設定爲string，當初設定爲string的緣由其實很單純，由於接下來的倉儲。

倉儲是被設定爲專門讀寫聚合根的，並且也是由接口定義的，因而乎，若是要用泛型指定聚合根的ID類型，這裏就存在了問題，不一樣類型的ID會被認定爲不一樣類型的聚合，而沒法抽象出贊成的上層接口，因而乾脆就用string了。object是否OK咧？答案時候確定的，可是，鑑於ID常常有多是int這種東西，object會涉及到拆箱裝箱的效率問題，因而捨棄了，最終定下來用string了。

曾經考慮過的方案是，定義一個IWorkUnit的空接口，讓聚合根接口繼承，讓倉儲處理工做單元，就把ID類型的耦合從倉儲上解開了。

關於Shuttle的測試

若是對發佈訂閱事件有所修改，須要對數據庫中的記錄初始化（清空）才能保證其是想要的結果。

對於Shuttle是否支持運行時訂閱，即訂閱不須要重啓服務，還沒有測試，對於這種需求也還沒有思考完整。

最終仍是先把原先的DDD相關的內容放上來了，沒辦法，趕時間

可是，這裏我碰見了一個坑，Shuttle的

個人框架裏自定義了一個Config文件，而這時我在系統中獲取的默認Config的時候，竟然拿不到App.config中的內容

沒有查到相關資料，鑑於時間緣由，決定對源代碼進行修改，已經將Shuttle的部分項目加入了源代碼中。

可是，關於配置文件這裏仍是但願可以獲得答案，若是能夠指定默認配置文件，從而讓Configuration拿到正確的配置文件信息，那就是最好的了。

來自爲知筆記(Wiz)