很多人把领域驱动设计（DDD）当成一套统一方法，但它实际上是两套东西。 战略部分包括限界上下文、上下文地图、核心域、支撑域和通用子域，回答的是“业务边界在哪里”。战术部分包括聚合、实体、值对象、仓储，回答的是“边界内部怎么构建”。 这两半几乎是正交的。上下文地图不要求你使用聚合，聚合也不要求你先画上下文地图。你可以只做战略而完全不做战术，也可以只做战术而完全不看全局。现实中两种偏科都很常见：有人认真画了上下文地图，却在边界内部做出贫血服务；有人写出了教科书式的聚合，上面却没有任何一张地图。 这两半是可以拆开的。由此带来一个少有人真正接受的结论：你可以保留其中一半，替换另一半。 这很重要，因为真正有争议的是战术部分。关于 DDD 的争论，几乎都是在争论聚合——聚合应该多大、事务边界应该在哪、关系数据库之下聚合是否还成立。很少有人会站出来说“限界上下文是个坏主意”。 所以方案是：保留上下文地图。它在做实际工作，而且它不依赖你在一个上下文内部如何拆分。然后，在每个上下文内部，按变更驱动因素来拆分，而不是按聚合来拆分。 变更驱动因素，是让代码发生改变的理由。它是一种力量，它一动，代码就得跟着动。它不是功能，也不是模块，而是一个原因。定价策略是一个变更驱动因素，监管机构是一个变更驱动因素，存储决策也是一个变更驱动因素。 给已有地图加三个注解就够了：第一，标出每个上下文最主要的变更驱动因素；第二，标出这些驱动因素之间如何相互影响；第三，标出哪些是稳定的外部契约，哪些是可以随时替换的内部实现。这三个注解不会改变上下文地图，但会决定你在每个上下文内部怎样设计。 换句话说，上下文地图是你买下的地皮，聚合只是地皮上可以拆掉的建筑。保留地皮，重建建筑。

打开网易新闻 查看精彩图片