《领域驱动设计》干货整理

repository代码设计

1. 可以将repository理解为一个集合（这里的集合更偏重于是collection，而不是set），它包括了对存储对象基本的增删改查（curd）功能。同时，repository还包括满足领域层的一些特定的功能（注：在repository中包括这些功能是合理的，首先这些功能是底层设施应该提供给上层的领域层的，其次在这里实现可以更好的利用底层设施的特点来进行性能优化）（注：在一般领域驱动设计的项目中分层都是上层依赖下层，这里的设计却更偏向于下层基础设施层依赖于上层领域层。应该可以发现，这里respository的需要包含的功能都是由上层领域层需要什么决定的，而不是由下层基础设计层能提供什么决定的。笔记认为这样的设计其实是更合理的，《clean architecture》一书的作者也与笔者持有相同的观点。这个问题的讲述可以单独写一篇博客，再这篇文章里不再细究）。
2. 不是每张表都需要有一个repository(在mybatis中aka：mapper）与之对应，更准确的说：应该将数据库中的全部表表聚积到几个根对象上（聚积方法后面讲），这个根对象应该有repository，而聚积在这个根上的对象不应该有repository。对这些非根对象的访问，应该通过于根对象的对象关系来实现。
3. （注：和第一条紧密相关，我暂时没有想清楚他俩之间的联系）正确的组合搜索于关联。搜索，即通过给repository传递查询参数来获取对象；关联，即通过要访问对象与通过搜索得到的对象的关联来获取对象。
4. repository应该是一个接口，将其实现与领域层的需求解耦。同时，方便测试时进行插桩和mock。
5. 虽然通过接口解耦了repository与领域层，但是即便是领域层的开发人员，也应该清楚repository的实现。避免出现性能问题。
6. repository不插手事务，将事务管理交由上层领域层和应用层管理。

7. repository应该让客户感觉到那些对象就好像驻留再内存中一样。

   数据库模式（database schema）设计

笔者认为的书中不严谨的地方

1. p104，书中写道：

   当然，如果在java中查询所返回的对象是集合时，客户不管怎样都要执行这样的转换。
   java1.4添加了泛型之后，返回集合时，不再需要用户进行强制类型转换。作者写书时，java1.4应该还没有发布，所以这样描述并没有错误。但是，这可能给后来的读者造成一些困惑。

todo

1. p102页中提到的一种灵活的、声明式的表示搜索标准的方法于mybatis中的example的概念有点儿像，之后研究一下俩者的关系。
2. 书中反复提到的entiry与valueobject的区别笔者一直没有太明白，之后需要研究一下这块儿。