第1章 领域驱动设计的原则与实践

1. 领域驱动设计的原则与实践

  DDD专注于介绍分解复杂问题空间的原则和实践，以及构成可维护空间的实现模式和最佳实践。如何使用有效的战术模式构建有效领域模型，以及如何通过应用DDD的战略模式来保护他们的完整性。

  虽然DDD的战术模式很有用，但是帮助你架构可维护和可扩展应用程序的是其原则，实践和战略模式。

  在了解DDD如何处理复杂性之前，理解哪些问题会造成软件陷入不可管理状况是很重要的。

1. 为复杂问题创建软件的挑战

迄今为止，用于商业应用程序的最流行的软件设计模式是大泥球，就是一大片随意构造，杂乱无章，凌乱，任意拼接，毫无头绪的代码丛林。

当工作流的常规变更和小功能增强由于阅读和理解现有代码存在困难而变得难以实现，让软件融入BBoM之中。

软件变得复杂及难以管理的一个主要原因在于，领域复杂性和技术复杂性混合在了一起。

 

1. 1. 未使用通用语言创建的代码

对于公共语言和问题域知识缺乏重视会导致代码库可用但无法揭示业务目的。

与业务能够理解的分析模型没有联系的代码随着时间推移其效果将减弱，因此很可能导致与BBoM模式类似架构。

1. 1. 组织结构的缺乏

代码缺乏与业务行为的协同效用，无法让变更可控。

问题域的复杂性通常会夹杂着技术解决方案的偶发复杂性。

 

1. 1. 泥球模式将扼杀开发

团队抱怨不断；

归根结底，BBoM对于作为开发人员的你来说是坏消息，因为它是杂乱无章的容易出错的代码，对于企业来说，它降低了其快速实现商业价值的能力。

 

1. 1. 缺乏问题域的关注

不能充分理解业务领域，软件项目就会失败。

编码是开发过程中最简单最自然的一部分。

在非功能性需求之外创建并维护一个能够满足业务用例的领域的软件模型才是难点所在。

 

1. 领域驱动设计模式如何管理复杂性

DDD能够同时应对理解问题域以及创建有助于解决内在问题的可维护解决方案的挑战。

1. 1. DDD的战略模式

1	提炼问题域以揭示重要之处是什么 开发团队与领域专家会使用分析莫斯和知识处理来将大的问题域提炼成更具管理的子域。
2	创建一个模型以解决领域问题 在解空间中，会为每一个子域构建一个软件模型以处理领域问题并让软件与业务保持一致。这个模型是一个虚拟的，非现实结构。
3	使用公共语言开启建模协作 通信是使用一种称为通用语言UL的不断发展的公共语言来实现的，以便快捷高效第将软件模型和概念分析模型链接在一起。 软件模型是通过为其结构和类设计使用UL的相同术语来绑定到分析模型的。
4	将模型与歧义和损坏隔离 模型是与基础架构代码隔离的，以避免技术与业务概念融合的偶发性。 通过将模型完整性与第三方代码隔离，有界上下文还能阻止模型完整性被损坏。
5	理解上下文之间的关系 DDD理解确保和业务在独立模型和上下文如何共同工作以便解决跨越子域的凌云问题方面要非常清除的需求。 上下文映射能够让你理解宏观的情况： 他们使得团队能够理解存在哪些模型，他们的职责是什么，以及他们的适用边界在哪里。

 

 

1. 1. DDD的战术模式

DDD的战术模式，也称为模型构造块，是一个帮助创建用于复杂有界上下文的有效模型的模式集合。

注意，这些模式并不适用于所有模型，并且每一种模式都必须应用正确的架构样式才能利用其本身的优势。

 

1. 1. 问题空间与解空间

 

 

1. 领域驱动设计的实践与原则
   1. 专注于核心领域

DDD强调的是在核心子域付出最多努力的需要。

团队要理解核心子域是什么。

 

1. 1. 通过协作进行学习

1. 1. 通过探索和试验创建模型

 

1. 1. 通信

UL的协作与构造使的DDD如此强大，它使得业务和开发团队对问题域的更多理解和更有效的通信成为可能。

 

1. 1. 理解模型的适用性

避免或者注意术语的歧义，如果可以，则分割为两个上下文。

 

1. 1. 让模型持续发展
2. 领域驱动设计的常见误区

DDD本身并非一个严格的方法论，而是必须与一些迭代式软件项目方法论的形式结合使用以构建并演化一个有用的模型。

 

1. 1. 战术模式是DDD的关键

DDD与其说是软件设计模式，不如说是通过协作来解决问题的方法。

 

1. 1. DDD是一套框架

某个产品可能遵循以事件为中心的架构的有界上下文。

另一个产品可能使用了分层的富领域模型；

而第三个产品可能应用了活动记录模式。

 

1. 1. DDD是一颗灵丹妙药

DDD可能需要付出大量努力，它需要迭代式方法论，以业务为导向以及聪明的开发人员。

 

1. 要点汇总