1 用户需求场景分析，识别业务全景 use case。这一个阶段重点识别 actor 和 use case。

2 分析模型鲁棒图，识别出业务场景中所有的实体对象。识别边界类（类似 ui）、控制类（类似 controller）和实体类（类似model）三种类型。

3 领域划分，将所有识别出的实体对象进行分类。

比如，主订单、子订单对象和归类到交易域；买家、卖家对象可以归类到会员域。

当然，最终所有的对象是归类到十个域还是二十个域，从理论上看，可以看做一次排列组合过程。只是，我们往往可以根据以往的经验、业务知识，做一个初始的域划分（但不见得是靠谱的）。因此，我们可以认为一个域实际上是一个或多个实体对象的信息集合，并对所管理的实体对象的生命周期进行管理。

4 评估域划分合理性，并进行优化。域划分并一定总是能得到唯一的答案，但可以得到最好的答案。评价一个域划分方案是不是足够好，其实是要根据“高内聚、低耦合”的原则进行评分。这一步就要画时序图了。

时序图的泳道，应该先设计到域颗粒度。可以看到域之间的交互，也就可以看到域之间的交互的复杂度。在绘制过程中，我们可以看域与域之间的调用是否过于频繁？甚至是反复调用不同的域服务？如果存在这种情况，就意味着这两个域之间存在比较严重的耦合。这往往通过直观就能有个大致的判断。如果要从定量角度来分析，可以参考代码圈复杂度的度量算法，我们也可以设定一个“域依赖度”算法，来衡量域与域之间的依赖度。对于依赖度比较高的几个域，我们可以采用：1）域合并 2）域拆分 3）提取第三方域做依赖倒置等降低耦合。

合理的域划分，内部的模型是可枚举的，稳定的，也就不易变的。