工作日志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)