建立领域驱动设计统一过程

领域驱动设计肇始于Eric Evans出版于2004年的著作《Domain-Driven Design-Tackling Complexity in the Heart of Software》：

领域驱动设计作为一个软件系统综合分析和设计的面向对象建模过程，如今已经发展为一种针对大型复杂系统的领域建模过程体系。

它改变了传统软件开发工程师针对数据库建模的方法，而是面向领域，将要解决的业务概念和业务规则转换为软件系统中的类型以及类型的属性与行为，通过合理运用面向对象的封装、继承、多态等设计要素，降低或隐藏整个系统的业务复杂性，并使得系统具有更好的扩展性，应对纷繁多变的现实业务问题。

领域驱动设计的立意是建立 以领域为驱动力 的过程体系，在这一核心驱动力的设计思想指导下，并没有死板僵化的构建过程来约束你。 Eric Evans定义了一套领域驱动设计元模型，该模型由诸多松散的模式构成：

至今，这套元模型在领域驱动设计的实施中仍然发挥着重要作用。

显然，领域驱动设计是开放的。 从领域驱动设计诞生至今，整个社区并未放弃发展其体系的努力，也诞生了许多重要的补充模式，例如以“领域事件（Domain Event）”为核心的诸多模式： 事件溯源（Event Sourcing）、CQRS模式等。

随着微服务和中台战略的兴起，领域驱动设计元模型中的限界上下文（Bounded Context）、核心领域（Core Domain）又得到了空前绝后的重视。

然而，在团队运用和实践领域驱动设计过程中，整套体系始终存在力有未逮之处。 毕竟，领域驱动设计是否能够取得成功，不只限于一两位精通领域驱动设计的专家就可以力挽狂澜。 团队成员的能力、管理规范等诸多因素都会影响整个实践的过程。

据我个人的经验和对实施领域驱动设计的反思，认为现行的领域驱动设计存在以下四个不足。

Eric Evans构建的领域驱动设计元模型并不足以支撑软件的构建过程。这些模式之间虽然彼此影响，运用得当就能形成设计合力； 然而模式的粒度并不均衡，运用上极为随意，缺乏一个统一的过程指导。

虽然领域驱动设计划分了战略设计阶段与战术设计阶段，但这两个阶段的划分仅仅是对构成元模型的模式进行类别上的划分，例如将限界上下文、上下文映射等模式划分到战略设计阶段，将聚合、实体、值对象等模式划分到战术设计阶段。

缺乏一个统一的过程去规范这两个阶段需要执行的活动、交付的工件以及阶段里程碑。Eric Evans没有清晰定义这两个阶段该如何衔接，它们之间执行的工作流到底是怎样的。

除了极少数精英团队，大多数团队都需要一个清晰的软件构建过程，否则将茫然不知所措。 领域驱动设计没能形成这样的统一过程，就使得其缺乏可操作性，团队在运用领域驱动设计时，更多取决于设计者的行业知识与设计经验，使得领域驱动设计在项目上的成功存在较大的偶然性。

因此，领域驱动设计缺乏一个规范的过程指导，是其不足之一。

领域驱动设计倡导以“领域”为核心驱动力，无论是对领域知识的抽象还是精炼，本质上都是针对问题域的业务需求。

可是，业务需求是如何获得的呢？ 获得的业务需求应该具备什么样的特征？ 业务需求的粒度和层次是怎么定义的？ 该如何规范和约定团队各个角色对需求分析的参与？ 以及在不同的阶段，业务需求的表现形式与验证标准分别是什么？

种种问题，领域驱动设计都没有给出答案，甚至根本就未提及！虽然说 这些问题都可以纳入到需求管理体系，故而可以认为它们游离于领域驱动设计之外； 可是，不同层次的业务需求贯穿于领域驱动设计过程中的每个环节，识别限界上下文需要对业务需求和业务流程有着清晰的理解，建立领域模型需要的领域知识和概念也都来自于用户故事层次的业务需求。毫无疑问，需求管理体系会直接影响领域驱动设计的质量。

因此，领域驱动设计没有匹配的需求管理体系，是其不足之二。

领域驱动设计战略阶段的核心模式是限界上下文，指导架构设计的主要模式是分层架构，前者决定了业务架构，后者决定了系统架构。

领域驱动设计的核心诉求是让业务架构和系统架构形成绑定关系，以面对需求变化时，使得系统架构能够适应业务架构的调整，满足架构的演进性。 领域驱动设计虽然给出了这些模式的特征，却失之与简单松散，不足以支撑复杂软件项目的架构需求。

因此，领域驱动设计缺乏面向领域的架构体系，是其不足之三。

领域驱动设计以模型驱动设计为主线，却没有给出明确的领域建模方法。

无论是否采用敏捷的迭代建模过程，建模分为分析、设计与实现这三个不同的活动确是客观存在的事实。虽然我们必须努力保证领域模型的一致性，但这三个活动存在明显的存续关系，每个活动的目标、参与角色与建模知识存在本质差异，这也是客观存在的事实。

基于此，我们需要分别为领域分析建模、领域设计建模和领域实现建模提供对应的方法指导，减轻每个建模活动的知识负担，明确每个建模活动获得的领域模型的验证标准，避免领域建模的随意性。

因此，领域驱动设计没有领域建模固化流程的支撑，是其不足之四。

针对领域驱动设计的四个不足，我对领域驱动设计的知识体系进行了精简与丰富。

精简，意味着做减法，就是要剔除领域驱动设计元模型中不太重要的模式，凸显核心模式的重要性，并对领域驱动设计过程进行固化，提供更为直接有效的实践方法，建立具有目的性和操作性的构建过程。

丰富，意味着做加法，就是突破领域驱动设计的范畴，扩大领域驱动设计的外延，引入更多与之相关的知识体系来丰富它，弥补自身的不足。

要构建全新的领域驱动设计体系，还需要匹配软件构建的目标。 软件构建就是不断对问题域求解，获得解决方案进而组成完整解决方案域的过程。 若要构建优良的软件系统，那么在这个构建过程中，还需要控制软件的复杂度。 因此，我们需要在问题域与解决方案域的背景下定义能够控制软件复杂度的领域驱动设计过程，并将体系的内容限定在领域关注点的边界之内，避免体系的扩大化。