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