（一）什么是领域驱动设计

什么是领域驱动设计

领域驱动设计是Eric Evans 定义的一种发展理念，

• 软件中的复杂性：包含“某种程度上确实有用但没法解释如何运行但代码”。软件变得复杂及难以管理但一个主要缘由在于，领域复杂性和技术复杂性混合在来一块儿。

复杂问题域产生的缘由（泥球模式）

软件复杂性：偶发性技术复杂性和领域逻辑复杂性。

• 1.未使用通用语言建立的代码：对于公共语言和问题域知识缺少重视会致使代码库可用但没法揭示业务目的，这会使得代码库难以阅读和维护，由于分析模型与代码模型之间的转译将会代价高昂且容易出错。备注：分析模型：分析模型用于描述一个软件应用程序的逻辑设计与结构。它能够由示意图或使用UML这样的建模语言来表示。它是软件的一种表现形式，让非技术人员可以概念化以便理解软件是如何构造的。
• 2.组织结构的缺少：一个系统的最初体现是快速制做且一般能得到面面俱到的成功，但因为缺少基于围绕问题域模型的应用程序设计的重视，后续的功能扩展就会变得很棘手。

泥球模式的危害

• 1.泥球模式将扼杀开发：开发团队会不断抱怨在如此一团混乱的状况下难以开展工做。开发速度的增加水平也没法知足业务需求。
• 2.缺少对问题域的关注：当不能充分理解正在处理的业务领域时，软件项目就会失败。编码不该该是困难的哪一环，维持一个可以知足业务用例的有用软件模型才是难点所在。

什么是问题域

问题域涉及你当前正在构建软件的主题领域。DDD强调的是在致力于为大型复杂业务系统建立软件时专一领域要高于其余的一切的需求。

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

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

DDD 的战略模式

• 1.提炼问题域已揭示重要之处是什么。

  开发团队与领域专家会使用分析模式和知识处理来将大的问题域提炼成更具管理性的子域。核心领域是出于开发过程的产品背后的驱动力；它是构造产品的根本缘由。

  探索核心领域有助于团队理解他们制做软件的缘由以及软件对业务达成的成就意味着什么。对业务目标的鉴定将使得开发团队可以肯定系统的重要部分并为之投入精力。随着业务的发展，软件也必须相应发展；它须要具有可修改能力，对应用程序关键区域的代码质量进行投入将有助于应用程序跟上业务的变化节奏。

• 2.建立一个模型以解决领域问题 在解空间中，会为每个子域构建一个软件模型以处理领域问题并让软件与业务保持一致。该模型并不是现实世界的模型，而更多的是构建来知足业务用例需求的一个抽象体，同时仍保持业务领域的规则和逻辑。

• 3.使用公共语言开启建模协做 模型使用公共语言构建（UML），以便快捷高效地将软件模型和概念分析模型链接在一块儿。编码时的术语会被映射到公共语言中，在业务分析时隐藏的概念也会被反馈到代码中。这正是领域专家和开发团队可以在协做中逐步发展模型的关键。

• 4.将模型与歧义和损坏隔离 模型位于有界上下文内，定义了模型的适用性并确保保留其完整性。有界上下文用于造成一个围绕模型的防御边界，这是经过容许整体解决方案的不一样模型在良好定义的业务上下文内部逐步发展来达成的，这样就不会带来对系统其余的负面连锁影响。

模型是与基础架构代码隔离的，以免技术与业务概念融合的偶发复杂性。经过将模型完整性与第三方代码隔离，有界上下文还能阻止模型完整性被损坏。

• 5.理解上下文之间的关系

DDD 理解确保团队和业务在独立模型和上下文如何共同工做以便解决跨越子域的领域问题方面要很是清楚的需求。

DDD的战术模式

DDD的战术模式是一个帮助建立用于复杂有界上下文的有效模型的模式集合。(企业应用架构模式 ,设计模式)

问题空间与解空间

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

• 专一于核心领域
• 经过协做进行学习
• 经过探索和实验来建立模型
• 通讯
• 理解模型的适用性
• 让模型持续发展

领域驱动设计的常见误区

• 战术模式是DDD的关键 对于开发人员来讲，在开发人员不关心或不理解的领域方面，发如今代码中实现的DDD战术模式远比发现业务用户和团队之间的会话要容易多。这就是DDD会被误认为不过是由实体，值对象和存储库构成的一种模式语言。

• DDD是一套框架

• DDD是银弹

总结

不在与业务是否可以用到，关键是你是否具有某种能力。这个才是付费的标准。