背景
- 从开始接触DDD到现在，也有一段时间了，中间断断续续的阅读了DDD的相关书籍及文章，中间思考了许多问题，不断地在stackoverflow上搜索，有些找到了满意的答案，有些回答看似让人满意，但实际写代码的时候，才发现往往不如最初想的那样简单。
- 学习一项新技术，除了阅读、思考，更重要的是使用，刚好最近项目组接到了一个新的需求，趁此机会决定把DDD真正地用起来看看。
- 本文所描述的实现方法很可能不是最好，但却是结合了自己最近一段时间学习+思考的结果。
需求
在未通过领域语言（Ubiquitous Language）进行描述前，我们对需求的主观理解大致是这样的：
- 记录一个用户最近访问过（点击）的客户列表，支持添加跟删除操作
- 记录用户关注的客户列表，支持添加跟删除操作
- 二者都有允许的最大客户数限制
- 最近访问列表允许丢失，保存在缓存中，关注列表则存储在数据库
- 其它：a) 为了简化操作，实际进行存储时，将列表转换为","分隔的String字符串进行保存。b) 客户的真正数据由另一个组件提供
由于需求简单，当时并没有过多的思考就进行设计。粗看起来，两个需求是差不多的，只是存储位置不一样，于是便按照下面的方式进行设计：
- 定义了一个模板方法
BaseXXXAppCustomerBiz，里面定义了append,delete,replace，query4个方法，分别用来做添加、删除、替换（调整顺序）、查询的对外接口，同时将真正对数据的增删改操作留给子类实现 - 上述两个需求用例，分别用两个子类实现，一个实现缓存模式下的读写逻辑，另一个实现数据库模式下的读写逻辑
当时自以为这是个很不错的设计，复用了逻辑，抽象了底层数据存储的原子操作。但是仔细一想，真的是这样吗？
思考
现在回过头来看，简直有点冒傻气，首先一个应该提的问题就是为什么这两个功能会在我们的系统内实现？
Anyway。。回过来思考一下，上述的两个用例，真的只是存储上的不同吗？
- 对于最近访问过的客户列表，超过列表阈值后， 我们可以用LRU算法替换掉队尾的客户，这不会有任何副作用。但是，对于关注的客户列表来说，超过最大客户数后，显然直接淘汰掉关注的客户是不合适的，这会让用户觉得很奇怪，为什么我关注过的客户会不见了，相反，使用明确的提示更合理。
- 最近访问过的客户列表不需要调整顺序的功能，因为是服务端自动触发的，对用户来说这个过程是透明的；只有关注的客户才需要调整顺序。
如果仔细思考真正的需求，使用领域语言来描述，那么可能会得到如下结果：
- 系统跟踪用户的访问行为：
- 当用户点击客户标签查看客户的具体信息时，将该客户添加到用户最近的浏览记录中；
- 系统默认保存的最近浏览记录数为20条，超过时自动删除最老的浏览记录；
- 允许用户设置是否要跟踪最近的浏览记录。
- 用户可以自己添加、删除需要关注的客户：
- 用户可以调整关注客户的展示顺序。
- 用户最大关注客户数为30，当超过此限制时提示用户。
- 新添加客户默认存放在关注列表的最后
通过上面的描述，可以看出来，两个需求有很大的不同。最近访问过的客户信息，本质上是一个系统的跟踪行为，随着系统的演化，可能还会引申出其它的跟踪事项；相反，用户添加关注客户的行为是一个主动行为，相对应地，他会更加关注交互的体验。
第一版实现
因此考虑不使用上述模板方法的实现，结合DDD，重新设计。那么很自然地，根据经典的DDD实现，会有这么两个类：
public class FxzcUser implements Aggregate {
private String userId;
private Queue<String> followingCusts;
private Queue<String> recentCusts;
// behavior: add, delete, ...
}
public class FxzcUserRepository implements Repository {
public void save(FxzcUser fxzcUser);
public FxzcUser ofId(String userId);
}
但实现的时候，马上遇到一个问题，正常来说，我们一般只会使用followingCusts跟recentCusts中的一个进行业务操作，这种情况下，把另一个队列也加载进来显然不必要。解决此问题通常有如下几种方案：
- 通过 Lazy Loading 实现，比如通过Hibernate等ORM工具自带的lazy loading机制，entity内部的对象只在真正需要时构造。网上关于是否应该使用Lazy Loading的讨论有很多，就自己而言，并不偏爱这种方式，因为他隐藏了你很多不知道的细节，有时候甚至可能造成大量的零散读取。
- 另一种方式，是使用Fetching Strategy，通过接口进行隔离，符合接口隔离原则。一个可能的实现方式为：
public interface IHandleFollowingCust {
List<String> allFollowingCusts();
void addFollowingCust(String custId);
void deleteFollowingCust(String custId);
void replaceFollowingCusts(List<String> custList);
}
public interface IHandleRecentCust {
List<String> allRecentCusts();
void addRecentCust(String custId);
void deleteRecentCust(String custId);
void replaceRecentCusts(List<String> custList);
}
public class FxzcUser implements IHandleFollowingCust, IHandleRecentCust, Repository {
}
这样拆分之后，在最近访问客户的场景中，使用IHandleRecentCust，在添加关注客户的场景中，使用IHandleFollowingCust，看起来似乎很好，但实现的时候，总感觉还是别扭，因为FxzcUser对应的实例，在运行时，实际上是一个不完整的状态，总让人担心如果哪天被谁突然不是使用接口而是直接对类进行操作，那么行为将变得不可控。
- 通过CQRS实现，这种方式相对复杂，在这个场景下暂时还不需要
第二版实现
其实，DDD中，设计聚合（aggregate）时，有一条很重要的原则，就是设计尽可能小的聚合，小到足以维持对应的invariant即可。
其次，根据彩色建模，在进行设计的时候，我们应该提醒自己时刻关注类的角色，因为角色决定了行为。
基于上面的思考，回过头来看，上面的FxzcUser实际上承担了两个角色，一个是记录跟踪，一个是客户关注，他们之间不存在功能上的依赖关系，我们有理由把原来的类拆分成两个，并且，可以把用户最近的浏览记录，放到单独的一个activity子包中。对应的实现方式为：
package com.chj.ddddemo.fzxc.domainV2.activity;
public class UserCustomerBrowsingHistory implements AggregateRoot {
private String userId;
private boolean isRecordHistoryEnabled;
private Deque<String> custList;
private static final int MAX_TRACK_CUSTS = 10;
public boolean addActivity(String custID) {
if (!isTrackingEnabled())
return false;
custList.remove(custID);
custList.addFirst(custID);
while (custList.size() > MAX_TRACK_CUSTS) {
custList.removeLast();
}
return true;
}
}
package com.chj.ddddemo.fzxc.domainV2;
public class UserFollowingCustomers implements AggregateRoot {
private String userId;
private List<String> customerList;
private static final int MAX_CUSTOMERS = 30;
public void followCustomer(String custId) {
if (customerList.contains(custId))
return ;
if (customerList.size() >= MAX_CUSTOMERS) {
throw new IllegalStateException("exceed maximum follow customers");
}
customerList.add(custId);
}
// ... other behavior
}
总结
上面其实是很简单的功能需求，但是通过DDD，我们发现了一些在最初实现中被忽略的因素。
目前来看，使用DDD有几个显而易见的好处：
- DDD迫使我们更多地去思考业务逻辑，挖掘出我们在需求沟通中没有发现的潜在信息。有时候，我们的设计会被我们的表达方式所影响。
- 使用DDD，会让我们自然地使用更有业务含义的名称来命名对象的方法，与Ubiquitous Language对应，提高代码的可读性
- 设计职责单一的、可维护的domain object，聚焦在类的角色及行为上，写出的代码更易理解及维护。
最后：上述示例代码可在 github 上查看
