领域驱动设计具有一定的开放性，只要遵循"以领域驱动为核心"的原则，就可以在软件构建过程中使用不限于领域驱动设计提出的方法，以控制软件的复杂度。
在不违背核心原则的情况，我们可以按照对它的理解，结合自身在项目中的实践来扩展整套方法论，这意味的我们自己也可以添加新的模式。如：
- 针对上下文映射提出发布者/订阅者模式
- 为限界上下文定义了菱形对称架构模式
- 在领域建模阶段增加了角色架构型的概念，提出了服务驱动设计
领域驱动设计现存的不足
在对现有领域驱动设计体系进行完善之前，需要充分了解它现存的不足。
- 领域驱动设计缺乏规范的统一过程
【对技能的要求过高。如果没有掌握其精髓，就难以合理地运用，团队在运用领域驱动设计时，更多取决于设计者的行业知识与设计经验使得领域驱动设计在项目上的成功存在较大的偶然性。】
- 领域驱动设计缺乏与之匹配的需求分析方法,
【针对问题空间的业务需求进行领域知识的抽象和精炼时，系统的问题空间是如何识别和界定出来的？问题空间的业务需求又该如何获得，具备什么样的特征？如何定义它们的粒度和层次？如何规范和约定团队各个角色对问题空间的探索和分析?在不同阶段，业务需求的表现形式与验证标准分别是什么？针对种种问题，领域驱动设计都没有给出答案。】
- 领域驱动设计缺乏规范化的、具有指导意义的架构体系。
【对于如何从问题空间映射到战略层次的解空间、问题空间的业务需求如何为限界上下文与上下文映射的识别提供参考等问题，领域驱动设计完全语焉不详。】
- 领域驱动设计的领域建模方法缺乏固化的指导方法
【领域驱动设计没有为领域分析建模、领域设计建模和领域实现建模提供对应的方法指导，要获得高质量的领域模型，主要凭借建模人员的验。】
领域驱动设计统一过程
针对领域驱动设计现存的4个不足，需要对领取驱动设计进行精简和丰富。剔除不重要的设计模式，凸显核心模式的重要性，对领域驱动设计过程进行固化，建立有目的性和可操作性的构建过程，突破领域驱动设计的范畴，引入更多与之相关的模式丰富它，弥补不足。
软件构件的过程就是不断对问题空间求解获得的解决方案，进而组成完整的解空间的过程，而领域驱动设计统一过程是将该过程执行的工作流限定在领域关注点的边界内，避免过程的扩大化。
统一过程的二维模型
领域驱动设计统一过程参考了统一顾虑的二维开发模型。如下图所示：
整个统一过程分成了三个阶段：全局分析、架构映射、领域建模；每个阶段都会有里程碑和产出物。里程碑作为阶段目标，可以作为该阶段的结束标志。每个阶段必须有产物产出，无论任何方式都是领域知识的一部分，并作为下一个阶段的输入，做参考、指导作用。产出物可做评审。
- 过程工作流：构成领域驱动设计统一过程的主要活动，它融合了领域驱动设计元模型，为工作流提供设计原则和模型的指导。
- 支撑工作流：严格来说不属于领域驱动设计的范围，但它们的选择却会对整个统一过程不断地印象实施领域驱动设计的效果。
每个工作流都可能贯彻统一过程的所有阶段，只不过因为阶段与目标活动的不同，工作流在不同阶段所占的比重各不相同，意味着在不同阶段花费的人力和成本与时间成本的不同。
统一过程的动态结构
领域驱动设计统一过程的动态结构通过3个阶段从问题空间到解空间完整而准确地展现了运用领域驱动设计构建目标系统的过程。这里所谓的“目标系统”是一个抽象的概念，取决于领域驱动设计统一过程的运用范围，既可大至整个组织，将该组织的所有IT系统都囊括在这一统一过程之下(问题空间的范围也将由此扩大至整个组织)，也可小至一个已有系统的新开发功能模块将其独立出来，严格遵循该统一过程，运用领域驱动设计完成其构建。目标系统的大小直接决定了问题空间的大小，自然也就决定了它所映射的解空间的大小。
全局分析
全局分析(big picture analysis)阶段的目标是探索与分析问题空间。该阶段主要通过对目标系统执行价值需求分析与业务需求分析这两个工作流，完全抛开对解决方案的思考与选择，仅仅从需求分析的角度以递进方式开展对问题空间的深入剖析。
从价值需求开始，识别目标系统的利益相关者，明确系统愿景，识别系统范围。
- 明确利益相关者与不同利益相关者的项目目标达成共识。
- 明确组织对目标系统树立的愿景，确保构建的目标系统能够对准组织的战略目标，避免软件投资方向的偏离。
- 了解目标系统的当前状态和预期的未来状态，确定目标系统的范围，从而界定问题空间的边界，为目标系统的解决方案提供战略指导。
- 价值需求分析实则描绘了目标系统的蓝图，指明了目标系统的方向，为我们确定和排列业务需求优先级提供了参考，为解空间进行技术选型和技术决策提供了依据，做出恰如其分的设计。
- 在价值需求的指导和约束下，根据用户发起的服务请求，逐一梳理出提供业务价值的动态业务流程，体现了多个角色在不同阶段进行协作的执行序列。
- 每个业务流程都具有时间属性，通过划定里程碑时间节点，即可在业务目标的指导下将业务流程划分为不同时间阶段的多个业务场景。
- 业务场景由多个角色共同参与，每个角色在该场景下与目标系统的一次功能交互，都是为了满足该角色希望获得的服务价值,由此即可获得业务服务。
- 在对业务需求进行深入分析后，结合价值需求分析的结果，将那些对准系统愿景的业务需求放到核心子领域，将提供支撑作用的业务需求放到支撑子领域，将提供公共功能的业务需求放到通用子领域，由此就可以从价值角度完成对问题空间的分解。
参与全局分析阶段的角色包括客户或客户代表、业务分析师、产品经理、用户体验设计师、架构师或技术负责人、测试负责人。其中，客户、业务分析师、产品经理共同扮演领域专家的角色，并在本阶段作为关键的
引导者和推动者。
架构映射阶段
架构映射(architectural mapping)阶段根据全局分析阶段获得的产出物，即价值需求与业务需求，分别从组织级、业务级与系统级3个层次完成对问题空间的求解，映射为架构层面的解决方案。
通过全局分析阶段完成对问题空间的探索后，对解空间架构层面的解决方案映射,几乎可以做到顺势而为。通过执行组织级映射、业务级映射与系统级映射这3个过程工作流，分别获得组织级架构、业务级架构与系统级架构。
- 在执行组织级映射时，设计者站在整个组织的高度在全局分析阶段输出的价值需求的指导下，通过系统上下文呈现利益相关者、目标系统与伴生系统之间的关系。系统上下文实际上确定了解空间的边界，除了系统边界与外部环境之间必要的集成，整个开发团队都工作在系统上下文的边界之内。
- 一旦确定了系统上下文，就可以根据全局分析阶段输出的业务需求执行业务级映射。根据语义相关性和功能相关性对业务服务表达出来的业务知识进行归类与归纳，即可识别出边界相对合理的限界上下文。限界上下文的内部架构遵循菱形对称架构模式，充分体现它作为自治的架构单元、领域模型的知识语境，提供独立完整的业务能力:限界上下文之间则通过不同的上下文映射模式表达上游和下游之间的协作方式，规范服务契约。
- 系统级映射建立在限界上下文之上，在全局分析阶段划分的子领域的指导下，在系统上下文的边界内部建立系统分层架构。该分层架构将属于核心子领域的限界上下文映射为业务价值层，将支撑子领域和通用子领域的限界上下文映射为基础层，并从前端用户体验的角度考虑引入边缘层，为前端提供一个统一的网关入口，并通过聚合服务的方式响应前端发来的客户端请求。
- 架构映射阶段的里程碑目标是完成从问题空间到解空间的架构映射，通过组织级映射、业务级映射和系统级映射获得遵循领域驱动架构风格的架构映射战略设计方案。
在本阶段，架构师(尤其是业务架构师与应用架构师)应成为关键的引导者和推
动者。
领域建模阶段
领域建模阶段是对问题空间战术层次的求解过程它的目标是建立领域模型。领域建模必须在领域驱动架构风格的约束下，在限界上下文的边界内进行。
这样一方面用分而治之的思想降低了领域建模的难度，另一方面也体现了领域建模依据的统一语言存在限定的语境，这也是模型驱动设计区别于其他建模过程的根本特征，根据领域模型表现特征的不同，领域建模可分为领域分析建模、领域设计建模和领域实现建模，对应于本阶段的3个主要过程工作流。
领域建模是一个统一而连续的过程。
- 执行领域分析建模时，以领域专家为主导，整个领域特性团队共同针对限界上下文对应的领域开展分析建模，即在统一语言的指导下对业务服务进行提炼与抽象，获得的领域概念形成领域分析模型；
- 执行领域设计建模时，以开发团队为主导，围绕每个完整的业务服务开展设计工作，获得领域设计模型；
- 领域实现建模仍然由开发团队主导，在拆分业务服务为任务的基础上开展测试驱动开发，编写出领域相关的产品代码和单元测试代码，形成领域实现模型。
领域分析模型、领域设计模型和领域实现模型共同组成了领域模型。
- 在执行主要的过程工作流时，还需要注意领域分析模型、领域设计模型和领域实现模型之间的同步，保证领域模型的统一。
推动领域建模完成从问题空间到解空间战术求解的核心驱动力是“领域”，在领域驱动设计统一过程中，就是通过业务服务表达领域知识，成为领域分析建模、领域设计建模和领域实现建模的驱动力。
领域建模阶段的里程碑目标是完成从问题空间到解空间的模型构建，通过领域分析建模、领域设计建模和领域实现建模逐步获得领域模型。领域模型包括如下内容。
- 领域分析模型:.业务服务规约和领域模型概念图。
- 领域设计模型:以聚合为核心的静态设计类图和由角色构造型组成的动态序列图与序列图脚本。
- 领域实现模型:实现业务功能的产品代码和验证业务功能的测试代码。
参与领域建模阶段的角色主要为领域特性团队业务分析师、开发人员和测试人员，其中业务分析师负责细化业务服务，测试人员为业务服务编写验收标准，开发人员进行服务驱动设计和测试驱动开发，共同完成领域建模。
统一过程的静态结构
领域驱动设计统一过程通过纵轴展现了工作流(work flow)，包括过程工作流与支撑工作流。其中在执行过程工作流时，还需要应用领域驱动设计元模型中的模式(pattern):或丰富到领域驱动设计体系中的方法(method)。
过程工作流
统一过程的所有过程工作流都运用了领域驱动设计的设计元模型。正是通过这种方式将相对零散的设计元模型糅合到一个完整的设计过程中，为开发团队运用领域驱动设计提供过程指导。为了更好地使领域驱动设计落地，我在沿用设计元模型的基础上，丰富了领域驱动设计体系，增加了一些新的方法，这些方法也可以认为是设计元模型的一部分。
支撑工作流
领域驱动设计统一过程需要对项目管理流程、需求管理体系和团队管理制度做出相应的调整，这些共同组成了统一过程的支撑工作流。
关于项目管理，Eric Evans早在十余年前就提到了敏捷开发过程与领域驱动设计之间的关系，他提出了两个开发实践：
- 迭代开发;
- 开发人员与领域专家具有密切的关系。
全局分析阶段与架构映射阶段也可采用迭代模式，但它们在管理流程上更像RUP的先启阶段。短暂快速的先启阶段与迭代建模的增量开发相结合，形成一种“最小计划式设计”。它是软件开发过程的中庸之道，既避免了瀑布型的计划式设计因为庞大的问题空间形成分析瘫痪(analysisparalysis)，又不至于走向无设计的另一个极端。
领域驱动设计的成败很大程度上取决于需求的质全局分析阶段的主要目标就是对问题空间进行价值量。需求分析与业务需求分析;在领域建模阶段，也需要领域特性团队的业务分析师针对全局分析获得的业务服务进行深入分析。这些都是领域驱动设计统一过程对需求管理流程的要求。
与需求管理流程不同，领域驱动设计统一过程并没有强制约定需求分析的方法，团队可以根据自身能力和方法的要求，选择用例需求分析方法，也可以选择协作性更强的用户故事地图或者事件风暴，甚至将多种需求分析方法与实践结合起来，只要能获得更有价值的业务需求。当然，为了让参与者能够在需求分析与管理过程中达成共识，也需要就需求术语定义“统一语言”。
领域驱动设计统一过程使用业务流程、业务场景、业务服务和业务任务4个层次的技术术语来体现不同层级的业务需求。
领域驱动设计对团队管理也提出了要求:“团队共同应用领域驱动设计方法，并且将领域模型作为项目沟通的核心。这一要求的目的是让团队成员更好地沟通与交流，并在团队内部形成一种公共语言，在开发节奏上保持与建模过程的步调一致。为了促进团队的充分交流，应为提供业务能力的限界上下文建立领域特性团队，为具有内聚功能的模块建立组件团队，针对客户端调用者尤其是前端UI建立前端组件团队，这种团队组建方式也符合康威定律的要求。