DDD概念概览 [0]

软件的核心,是为其用户解决领域相关问题的能力。

何为DDD

DDD是Domain Driven Design的简称。领域驱动设计,“领域”指业务领域,“设计”指软件设计。
DDD可以看成一种开发思想体系,促成了一种新的以领域为中心的思维方式,使得团队可以高效管理——用于复杂问题域的软件的构造和维护。

为什么DDD

对于一个复杂业务系统,无视业务复杂度而割裂式地进行软件设计,往往会造成软件的大泥球模式(BBoM),后果就是:

  1. 对统一语言和问题域知识缺乏重视,导致代码库可用但无法揭示业务意图。
  2. 缺乏基于问题域模型的应用程序设计的重视,让代码库缺乏与业务行为的协同效应,当有后续功能的扩展就会变得棘手。领域复杂性和技术复杂性混合在了一起。
  3. 会扼杀开发。对开发人员来说,软件杂乱、变更易出错。对企业来说,降低了软件快速实现商业价值的能力。
  4. 缺乏对问题域的关注和正确认识,构建出来的软件系统往往会失败。
    注:问题域 ,涉及你当前正在构建软件的主题领域。是确定软件价值的关键点。

DDD模式

DDD具有两种模式类型:战略模式和战术模式。
战略模式影响的是解决方案,战术模式用于实现富领域模型。


Domain Drive Design Summary.png

DDD战略模式

领域驱动设计的战略模式会提炼问题域并塑造应用程序的架构。

  1. 提炼问题域以揭示重要之处是什么 —— 核心子域。核心域是编写软件的原因,保留最大价值的关键区域,决定软件成功与否的关键。并非一个系统的所有部分都需要被精心设计,团队可以更专注于核心领域。
  2. 在解空间构建一个软件模型,以处理领域问题并让软件与业务保持一致。
  3. 运用统一语言(Ubiquitous Language),开启建模协作。首先,确保的是领域专家和开发团队协作工作,其次,是将分析模型绑定到代码模型,以便开发团队和领域专家能够在模型设计方面进行协作。
  4. 限界上下文(Bounded Context),定义了模型的适用性并确保保留其完整性和独立发展的能力。统一语言和模型的适用边界应该是要在具体的限界上下文内。
  5. 上下文映射(Context Map)。上下文映射提供了整个系统各上下文边界之间的宏观状况,揭示了上下文之间的关系和交互方式,同时表现出各上下文内模型的有多少差异,以及它们的交换哪些数据来实现业务处理过程。
问题空间 & 解空间

战略模式中强调问题空间和解空间的区别。只有明确确定了问题空间,才能分析出对应的解空间,最终才能构建出满足解决业务问题的成功软件。
上1,是解决问题空间复杂度的管理模式。问题空间将问题提炼成更多可管理的子域。
上2、3、4、5, 是解空间的管理模式。

战略模式强调了DDD的侧重点是:知识消化、知识提炼、协作沟通、统一语言、上下文、模型持续发展。
后面战术模式,其实只是支持其实现而推荐的手段。

DDD战术模式

DDD的战术模式(也称模型构造块)是一个帮助创建用于复杂有界上下文的有效模型的模式集合。
许多模式都早于DDD概念的出现,但依然有一些被推荐为DDD战术的标准模式。
在战略模式提供的架构和原则的基础上,共用这些标准模式可以让设计有序进行,也使项目组成员能够更方便地了解彼此的工作内容。

  1. 实体(Entity)
  2. 值对象(Value Object)
  3. 领域服务(Domain Service)
  4. 工厂(Factory)和验证器(Validator)
  5. 聚合(Aggregation)
  6. 资源库(Repository)
  7. 领域事件(Domain Event)
  8. 模块(Module)
  9. 集成限界上下文
  10. 六边形架构
参考文献
  1. 《领域驱动设计:软件核心复杂性应对之道》,Eric Evans 著
  2. 《实现领域驱动设计》,Vaughn Vemon 著
  3. 《领域驱动设计模式、原理与实践》,Scott Millett / Nick Tune 著

你可能感兴趣的:(DDD概念概览 [0])