什么是领域驱动设计
领域驱动设计是Eric Evans 定义的一种发展理念，
- 软件中的复杂性：包含“某种程度上确实有用但无法解释如何运行但代码”。软件变得复杂及难以管理但一个主要原因在于，领域复杂性和技术复杂性混合在来一起。
复杂问题域产生的原因（泥球模式）
软件复杂性：偶发性技术复杂性和领域逻辑复杂性。
- 1.未使用通用语言创建的代码：对于公共语言和问题域知识缺乏重视会导致代码库可用但无法揭示业务目的，这会使得代码库难以阅读和维护，因为分析模型与代码模型之间的转译将会代价高昂且容易出错。备注：分析模型：分析模型用于描述一个软件应用程序的逻辑设计与结构。它可以由示意图或使用UML这样的建模语言来表示。它是软件的一种表现形式，让非技术人员能够概念化以便理解软件是如何构造的。
- 2.组织结构的缺乏：一个系统的最初体现是快速制作且通常能获得面面俱到的成功，但由于缺乏基于围绕问题域模型的应用程序设计的重视，后续的功能扩展就会变得很棘手。
泥球模式的危害
- 1.泥球模式将扼杀开发：开发团队会不断抱怨在如此一团混乱的情况下难以开展工作。开发速度的增长水平也无法满足业务需求。
- 2.缺乏对问题域的关注：当不能充分理解正在处理的业务领域时，软件项目就会失败。编码不应该是困难的哪一环，维持一个能够满足业务用例的有用软件模型才是难点所在。
什么是问题域
问题域涉及你当前正在构建软件的主题领域。DDD强调的是在致力于为大型复杂业务系统创建软件时专注领域要高于其他的一切的需求。
领域驱动设计模式如何管理复杂性
DDD 能同时应对理解问题域以及创建有助于解决其内在的问题的可维护解决方案的挑战。
DDD 的战略模式
-
1.提炼问题域已揭示重要之处是什么。
开发团队与领域专家会使用分析模式和知识处理来将大的问题域提炼成更具管理性的子域。核心领域是出于开发过程的产品背后的驱动力；它是构造产品的根本原因。
探索核心领域有助于团队理解他们制作软件的原因以及软件对业务达成的成就意味着什么。对业务目标的鉴定将使得开发团队能够确定系统的重要部分并为之投入精力。随着业务的发展，软件也必须相应发展；它需要具备可修改能力，对应用程序关键区域的代码质量进行投入将有助于应用程序跟上业务的变化节奏。
-
2.创建一个模型以解决领域问题 在解空间中，会为每一个子域构建一个软件模型以处理领域问题并让软件与业务保持一致。该模型并非现实世界的模型，而更多的是构建来满足业务用例需求的一个抽象体，同时仍保持业务领域的规则和逻辑。
-
3.使用公共语言开启建模协作 模型使用公共语言构建（UML），以便快捷高效地将软件模型和概念分析模型连接在一起。编码时的术语会被映射到公共语言中，在业务分析时隐藏的概念也会被反馈到代码中。这正是领域专家和开发团队能够在协作中逐步发展模型的关键。
-
4.将模型与歧义和损坏隔离 模型位于有界上下文内，定义了模型的适用性并确保保留其完整性。有界上下文用于形成一个围绕模型的防护边界，这是通过允许总体解决方案的不同模型在良好定义的业务上下文内部逐步发展来达成的，这样就不会带来对系统其他的负面连锁影响。
模型是与基础架构代码隔离的，以避免技术与业务概念融合的偶发复杂性。通过将模型完整性与第三方代码隔离，有界上下文还能阻止模型完整性被损坏。
- 5.理解上下文之间的关系
DDD 理解确保团队和业务在独立模型和上下文如何共同工作以便解决跨越子域的领域问题方面要非常清楚的需求。
DDD的战术模式
DDD的战术模式是一个帮助创建用于复杂有界上下文的有效模型的模式集合。(企业应用架构模式 ,设计模式)
问题空间与解空间
领域驱动设计的实践与原则
- 专注于核心领域
- 通过协作进行学习
- 通过探索和实验来创建模型
- 通信
- 理解模型的适用性
- 让模型持续发展
领域驱动设计的常见误区
-
战术模式是DDD的关键 对于开发人员来说，在开发人员不关心或不理解的领域方面，发现在代码中实现的DDD战术模式远比发现业务用户和团队之间的会话要容易多。这就是DDD会被误认为不过是由实体，值对象和存储库构成的一种模式语言。
-
DDD是一套框架
-
DDD是银弹
总结
不在与业务是否能够用到，关键是你是否具备某种能力。这个才是付费的标准。