工作这么多年，还没几到在划域比较认可的，本文更多收集反例。反例观点不一定对，先破掉人想当然之习惯。
订单域
由此我们可以得到实体和领域之间的关系：实体和领域之间是多对一的关系。一个实体不能称为一个领域，只有多个职责相似度很高的实体集合，才能被称为一个领域。一个实体只属于一个领域，如果实体属于多个领域，可能就需要思考下，这多个领域究竟是不是同一个域。领域是有职责来管理实体的生命周期的，这种管理是战略上的管理，不是战术上的，就是无法落地成代码的，只有实体才能够落地成代码，领域不能。
所以我们才在开头定义领域为：相似度很高的 N 个实体聚集，组成的知识、影响或活动范围。
比如说交易域是由订单实体和订单明细实体等多个实体组成的知识范围，营销域是由营销活动实体和营销工具实体等多个实体组成的知识范围。
反例比如说，咱们有个订单实体，于是就有同学发明出订单域的叫法，这种叫法其实是不准确的，一个实体不能称为域。
预售域
再反例比如说，电商行业有个东西叫做预售，举个预售的例子，小明今天下单预购买电视机，付定金 500 元，剩下尾款是需要在 10 天后支付，通过这种形式，商家提前锁定买家，买家也能得到一些优惠，那么就有一些同学针对这个业务提出了新的领域：预售域，主要理由就是预售在商品发布、商品详情、下单页、订单详情页面等多个地方，都有预售的影子，都有和预售相关的业务，所以预售也可以称作一个领域，这样对么？
很明显是不对的，预售我们只能称为一个下单场景，只不过这个场景在很多领域下都有设置一些值，比如规定了只有商品 A 才能参加预售，比如规定参加预售下单的订单详情页面不太一样，但我们无法从预售这个下单场景中，抽象出和预售职责相似度很高的实体，一个实体都无法抽象出来。
如果你把预售这样的场景称为领域，那么随着业务的发展，你会很恐怖地发现，你的域太多了，比如限购域、0 元商品域、阶段支付域，场景是无穷无尽的，你的领域也会无穷无尽。
所以我们划分领域的时候，最忌讳的就是以场景来划分领域，我们应该以业务对象聚合来划分领域。
限购域
如，在交易下单系统中，⽬前还有⼀个域叫做限购域。按照过往的业务背景知识，⼤家很容易易接受这个域。觉得很合理理啊，下单时有各种各样的限购情况。可是，当我们将所有的限购场景使⽤用鲁棒图绘制时就发现，这些限购场景涉及到的对象如下：按买家维度做限购：⽐比如按照买家的信⽤用级别等进⾏行行限购管理理（更更新买家信息，如打标等），涉及的对象是买家对象。买家对象应该是由“会员域”去管理理啊~~~
按商品维度做限购：⽐比如，给特定商品打⼀一些标，这样能对这类商品进⾏行行区域限购。及的对象是商品对象。商品对象应该是由“商品域”去管理啊~~~
按曾经是否享受过特价优惠做限购（⽐比如半年年内买过特价商品，半年年内不不能再买）。
这个涉及到的对象有买家和订单等信息。
很显然，限购这个域是按照“场景”维度进⾏行行提取的，⽽而不不是根据“对象”进⾏行行汇聚产⽣生的。这么划分，会产⽣生的⼀一个问题是，“场景”是不不可枚举的、易易变的。今年年有10个应⽤用场景，明年年随着市场的发展，可能⼜又有20个应⽤用场景。如果，按照“场景”维度去做域划分，就会导致按
照这种⽅方式划分的域，是不不稳定的！
