DDD（领域驱动设计）--战略设计

领域

领域是一个组织所作的事情以及其中所包含的一切。商业机构一般会肯定一个市场，而后在这个市场中销售产品和服务。每一个组织都有它本身的业务范围和作事方式。
领域就是解决一个特定范围内的业务问题。

如何分析领域

在研究与建模的过程当中，开发人员是不能孤军奋战的，这个时候须要找领域专家一块儿建模，领域专家是精通业务的任何人，他们多是软件产品的设计者，甚至有多是销售。
领域专家把他的知识传给开发者，让建模更符合实际业务状况，以此也能得到更好的用户体验。

子域

分而治之，DDD是一套处理复杂领域的设计方法。
当咱们遇到一个复杂的问题时，一般的作法就是将问题一步一步地细化，再针对细化出来的问题域逐个深刻研究。当全部的子问题都完成研究时，咱们也就创建了所有领域的完整知识。
子域是整个业务领域的一部分，大多数的业务领域都过于庞大和复杂，难以做为总体来分析，所以须要对整个业务领域进行拆分。

子域划分

• 核心域：它是一个定义明确的领域模型，须要投入大量资源去精心打磨的子域。它是组织中最重要的模块，由于这将是和其余竞争者的区别所在，须要把这个核心域打形成为组织的核心竞争力。
• 支撑域：这类子域，可能找不到现成的解决方案，对它的投入如何也达不到与核心域相同的程度。但核心域的成功离不开支撑域。这个子域不须要过分地考虑可扩展性和兼容性，若是要考虑的，应该是可替代性。这也就要求支撑子域须要有明确的契约规范和业务约束条件。这种子域通常提倡“定制开发”。
• 通用域：通用子域内的业务规则相对明确，通常解决方案能够经过采购获取，对其定制化要求比较低，而稳定性和兼容性则要求较高。

现实世界中领域与子域

领域中还同时存在问题空间和解决空间。在问题空间中，咱们思考的是业务所面临的挑战，而在解决方案空间中，咱们思考如何实现软件以解决这些业务挑战。

通用语言（Ubiquitous Language）

平常开发过程当中，你们应该都有这种感觉，在和产品经理、运营等交流过程当中，常常会有各类扯皮，无法沟通的时候，很大一部分缘由就是你们沟通的时候，用词含义不一致致使的。
要想建立一种灵活的、蕴含丰富知识的设计，须要一种通用的、共享的团队语言。若是语言支离破碎，项目必将受阻，实现过程当中可能得不到符合要求的产品。
因此咱们须要有一套通用语言，领域专家、产品、开发、运营等通用的语言，须要包括类和主要操做的名称。并将这些通用语言应用到需求讨论、技术方案设计、图和代码中。

限界上下文（Bounded Context）

生物学中，咱们知道，细胞之因此可以存在，是由于细胞膜限定了什么在细胞内，什么在细胞外，而且肯定了什么物质能够经过细胞膜。
软件系统中也是同样，咱们须要有一个限界上下文，明确地定义模型所应用的上下文，根据团队的组织，软件系统的各个部分的用法以及物理表现（代码合数据库模式）来设置模型的边界。在这些边界中严格保持模型的一致性，而不要受到边界以外问题的干扰和混淆。

限界上下文是一个显式的边界，领域模型变存在于这个边界以内。每个模型概念，包括它的属性和操做，在边界以内都具备特殊的含义。

在现实世界中，领域的边界很模糊，可是要设计一个好的解决方案，咱们须要对问题子域加上一个边界，将不重要的信息排除在边界外。让解决方案专心解决重点问题。

每一个上下文都表明着该解决方案的专业知识。在同一个上下文里，咱们共享统一的语言和一致的设计。
经过界限上下文人为将问题子域限制在有限的界限内，你才能够着手建立解决方案。

上下文映射（Context Mapping）

每一个限界上下文不可能独立存在，基本都须要与其余上下文进行集成，上下文映射是为了用来描述限界上下文之间的协做问题。这种集成关系在DDD中成为上下文映射，有以下几种映射方式。

合做关系（Partnership）：若是两个限界上下文的团队要么一块儿成功，要么一块儿失败，要么一块儿成功，此时他们须要创建起一种合做关系。合做越多依赖越多，耦合越严重，甚至出现双向依赖。

共享内核（Shared Kernel）：当不一样团队开发一些紧密相关的应用时，若是团队直接不进行协调，即便短期可以取得快速进展，但他们开发出来的产品可能没法结合到一块儿。最后可能不得不耗费大量精力在转换层上，而且频繁地进行改动，不如一开始就从领域模型中选出两个团队都赞成共享的一个子集，减小重复的工做。这种模式下，在没有与另外一个团队协商的状况下，这种状态是不可改变的，同时须要引入一种持续集成过程来保证共享内核与通用语言的一致性。

客户方－供应方开发（Customer-Supplier Development）：正常状况下，这是团队合做中最为常见的合做模式。当两个团队处于一种上游－下游关系时，上游团队可能独立于下游团队完成开发，此时下游团队的开发可能会受到很大的影响。所以，在上游团队的计划中，咱们应该顾及到下游团队的需求。

遵奉者/追随者（Confoemist）：下游团队直接使用上游团队的模型，简化集成。

防腐层（Anticorruption Layer）：防腐层经过已有的接口与其余系统交互，而其余系统只须要作很小的修改，甚至无须修改。在防腐层内部，它在你本身的模型和他方模型之间翻译转换。

开放主机服务（Open Host Service）：定义一种协议，让你的子系统经过该协议来访问你的服务。你须要讲该协议公开，这样任何想与你集成的人均可以使用该协议。

发布语言（Published Language）：在两个限界上下文之间翻译模型须要一种公用的语言。此时你应该使用一种发布出来的共享语言来完成集成交流。发布语言一般与开放主机服务一块儿使用。

另谋他路/各行其道（SpeparateWay）：在肯定需求时，咱们应该作到坚定完全。若是两套功能没有显著的关系，那么它们是能够被彻底解耦的。集成老是昂贵的，有时带给你的好处也不大。声明两个限界上下文之间不存在任何关系，这样使得开发者去另外寻找简单的、专门的方法来解决问题。

大泥球（Big Ball of Mud）：当咱们检查已有系统时，常常会发现系统中存在混杂在一块儿的模型，它们之间的边界是很是模糊的。此时你应该为整个系统绘制一个边界，而后将其概括在大泥球范围之列。在这个边界以内，不要尝试使用复杂的建模手段来化解问题。同时，这样的系统有可能会向其余系统蔓延，你应该对此保持警觉。

参考资料

• 《领域驱动设计——软件核心复杂性应对之道》
• 《实现领域驱动设计》
• DDD战略设计相关核心概念的理解
• 上下文映射与协做
• ThoughtWorks洞见-再谈领域驱动设计
• context-mapping