什么是领域驱动设计?

什么是域？

要进行定义，我们首先应该确定在这种情况下（以及一般而言在开发中）的含义。字典的常见定义是：“知识或活动领域”。在软件工程领域，对此进行深入研究通常指的是应用程序打算应用的主题领域。换句话说，在应用程序开发期间，它是“应用程序逻辑所围绕的知识和活动范围”。

在软件开发过程中使用的另一个通用术语是“ domain layer或” domain logic，这对许多开发人员来说可能更广为人知business logic。该business logic应用程序是指在更高级别的规则如何business objects相互作用彼此创建和修改模型数据。

什么是域驱动设计？

最初由程序员Eric Evans在其2004年的著作《_域驱动设计：解决软件核心中的复杂性》中_引入并广受欢迎，是该概念的扩展和应用，因为它适用于软件开发。它旨在通过将软件的相关部分连接到一个不断发展的模型中来简化复杂应用程序的创建。着重于三个核心原则：

• 关注核心domain和核心domain logic。
• 基于领域模型的复杂设计。
• 不断与领域专家协作，以改善应用程序模型并解决所有与新出现的domain问题。

Evans的_域驱动设计_进一步定义了一些通用术语，这些术语在描述和讨论DDD实践时非常有用：

• 上下文：背景。关于模型的声明只能在上下文中理解。
• 模型：描述a的选定方面的抽象系统，domain可用于解决与此相关的问题domain。
• 无处不在的语言：一种围绕该语言构造的语言domain model，所有团队成员都使用该语言将团队的所有活动与软件联系起来。
• 边界上下文：对边界（通常是子系统或特定团队的工作）的描述，在其中定义并应用了特定模型。

构建领域的模块

Domain-driven design还定义了许多高级概念，这些概念可以相互结合使用来创建和修改domain models：

• 实体：object通过其一致的连续性线程来标识的实体，与传统的实体（由其objects定义）相对attributes。
• 值对象：具有，但没有唯一标识的immutable（不可更改）。
• 域事件：一个对象，用于记录与系统内模型活动相关的离散事件。尽管可以跟踪系统中的_所有_事件，但仅为关心的事件类型创建a 。
• 集合体：组中具有entities并定义边界的集群。与其让每个单独或自己执行所有动作，不如将一组项目分配给单个项目。现在，外部对象不再可以直接访问每个人或内部的对象，而只能访问单个项目，并使用该对象将指令传递给整个组。该实践与我们在本系列中介绍的许多实际编码实践相关。
• 服务：本质上，service是业务逻辑的一种操作或形式，它自然不适合的领域objects。换句话说，如果某些功能必须存在，但不能与entity或关联，则可能是一个服务
• 仓库：不要与版本控制的仓库相混淆，DDD含义repository是service使用全局接口来提供对所有访问的访问，entities并且访问特定集合中的所有存储。应该定义方法以允许在中创建，修改和删除对象。但是，通过使用它进行数据查询，目标是从的业务逻辑中删除此类数据查询功能
• 工厂：DDD建议使用a factory，它封装了创建复杂对象的逻辑，并聚合确保客户端不了解对象操纵的内部工作。

Domain-driven design还非常强调的流行做法持续集成，它要求整个开发团队使用一个共享的代码存储库，并每天（如果不是每天多次）向其推送提交。在工作日结束时执行一个自动过程，该过程检查整个代码库的完整性，运行自动化的单元测试，回归测试等，以快速检测到最新提交中可能引入的任何潜在问题。

域驱动设计的优势

• 简化沟通：早期强调建立ubiquitous与domain model项目相关的通用语言，团队通常会发现在整个开发生命周期中的沟通要容易得多。通常，DDD在讨论应用程序的各个方面时，它们需要的技术术语较少，因为ubiquitous language较早建立的术语可能会定义更简单的术语来指代那些技术性更高的方面。
• 提高灵活性：由于DDD高度依赖于面向对象的分析与设计的概念，因此领域中的几乎所有内容都将基于对象，因此将具有相当的模块化和封装性。这允许定期，连续地更改和改进各种组件，甚至整个系统。
• 强调域DDD之上的接口：由于围绕项目的概念domain以及domain experts项目内所建议的内容进行构建的实践，与强调UI / UX的那些应用程序相反，DDD通常会产生准确地适合并代表当前domain用途的应用程序首先。尽管需要达到明显的平衡，但专注于domain意味着一种DDD方法可以生产出一种与之相关的受众共鸣的产品domain。

域驱动设计的缺点

• 需要强大的领域专业知识：即使拥有最精通技术的头脑来进行开发，如果domain expert团队中至少没有一个人知道该应用程序打算应用的主题领域的确切内容，这一切都是徒劳的。在某些情况下，可能需要整合一个或多个可以在整个开发生命周期中扮演角色的外部团队成员。
• 鼓励迭代实践：尽管许多人会认为这是一个优势，但不可否认的是，DDD实践强烈依赖于不断的迭代和持续集成，以构建可延展的项目，并在必要时进行调整。一些组织可能在这些实践上遇到麻烦，特别是如果他们过去的经验在很大程度上与诸如该waterfall模型之类的较不灵活的开发模型相关联。
• 不适用于高科技项目：虽然DDD非常适合domain复杂性非常高的应用程序（business logic相当复杂且令人费解DDD的应用程序）domain，但不适用于那些具有有限复杂性的应用程序，但是反之则有很大的优势技术复杂性。由于DDD过分强调需要（和重要性）domain experts来生成适当的项目ubiquitous language，然后domain model作为项目的基础，因此，技术上异常复杂的项目可能domain experts难以掌握，从而可能导致线下的问题，也许是在技术要求或团队的所有成员都没有完全理解局限性。