我的思考：该模式最大的优点在于：领域模型和数据库结构之间关系一致，利于理解；缺点在于：读取一个对象需要多表访问，性能上需要注意。
项目实践：无。
具体表继承模式概要：每个子类对应一个具体表，多个具体表之间可能存在相同的字段。
我的思考：该模式最大的优点在于：相比“类表继承”获取完整对象时，无需表连接查询；每个表都是自包含的，无不相关域；缺点在于：领域内全局主键较难处理；类继承层次该表对表结构影响较大。全局主键的问题可以考虑使用：Id+type这种联合主键的形式来解决，每个子表使用独立的seq，每个子表定义一个类型字段，映射到模型时，使用Id+type作为全局唯一主键；另外一种方案是：使用全局的seq，所有子表共用一个seq，坏处在于每个子表id的不连续性；公共seq可能成为资源瓶颈。
项目实践：用户体系的**账号表和理财账号表就是使用这种模式来建表的，当然现在是对**账号和理财账户进行独立建模，所以影响倒不是很大，但是此种模式的一个缺点较为明显：每次需要查询某个用户下的所有账户列表时，需要同时查询**账号和理财账号表，如果使用“类表继承”模式，则可以避免多表查询，因为在这个查询场景下，仅仅需要查询账户的基本信息：账号、开户日期，这些属性是所有账号共有的，因此完全可以从父表中获取。
资源库模式概要：协调领域和数据映射层，使用类似于集合的接口来访问领域对象。
我的思考：资源库repository是一个很常见的术语，它可以理解为一个存储层的gateway，也可以理解为一个存储层的facade，repository提供面向对象的查询原语，可以参考elasticsearch等内存数据库的api实现。在存在多个存储介质的系统中个，可以使用repository包装多个存储介质的实现，比如整合redis缓存和oracle主存配合使用的数据存取过程；还可以有基础自repository的哑实现，使用领域模型不必依赖于存储层也可以快速完成建模。
项目实践：用户体系和社区系统中均有使用到，使用场景见上面描述。课参考：【DDD】领域驱动设计实践 —— 一些问题及想法 中的“2、repository的实现”一节。
Web表现模式模式概要：经典的MVC模式，将‘视图（View）’、‘模型（Model）、‘控制器（Controller）’分离。
我的思考：MVC是非常经典的设计模式，从struts到springmvc，研究springmvc足矣，囊括了filter、inteceptor等基本组件。
项目实践：web类项目基本逃不掉MVC，不再赘述。