领域驱动设计的提出已经有将近 20 年的历史，在最近几年微服务兴起之后，人们发现领域驱动设计天然适配微服务架构，因此吸引了大量的关注。这篇文章以非常简洁的笔触介绍了 DDD 涉及到的一些概念定义，可以快速的建立起领域设计的基本概念。原文：DDD in a nutshell[1]
你可能已经听很多人谈论过 DDD，DDD 是领域驱动设计(Domain-Driven Design)的简称，有人把它想象成一种巨大而神奇的东西，但实际上它只是一组包含了许多组合模式和最佳实践的方法，帮助我们构建更好的软件。
领域驱动设计是指软件代码的结构和语言应该与业务领域相匹配的概念。例如，如果一个软件处理贷款申请，它可能有像 LoanApplication 和 Customer 这样的类，以及像 AcceptOffer 和 Withdraw 这样的方法。——维基百科[2]
有许多著名的书籍是关于领域驱动设计的，比如 Eric Evans 在 2003 年出版的《领域驱动设计——软件核心复杂性应对之道》[3]。但在本文中，我希望能以简单的方式帮助你理解 DDD 的全貌，后续你可以通过阅读相关书籍了解更多详细信息。
总体来说，关于 DDD 的讨论主要是关于战略和战术模式：
- 战略模式帮助你设计领域和子领域，利用通用语言进行交流，根据输出的结果支持团队的组织架构。
- 战术模式指导你如何以可伸缩的方式实现应用程序。
DDD 简介
战略设计（Strategic Design）
战略模式可以帮助你设计领域和子领域，这些领域通过通用语言进行交流，支持你根据结果组织/构建你的团队。
首先，需要定义通用语言，这将帮助团队就相同的术语达成一致，从而带来对定义或业务的相同理解。我想强调的是，这是必要步骤，应该在一开始就做，并在开发期间继续下去。
有界上下文帮助你定义主领域和子领域以及它们之间(上游和下游)的依赖关系。然后在此基础上，可以根据组件或服务来构造应用程序。最后，将团队组织起来，负责构建和维护这些服务。
战术设计（Tactical Design）
战术模式指导你如何以可伸缩的方式实现应用程序。
战术设计帮助基于构建块创建优雅的领域模型，参见下面的主要构建块：
聚合（Aggregates）
聚合是战术设计中最重要、最复杂的模式之一，聚合基于另外两种战术标准（Tactical Standards），即实体（Entities）和值对象（Value Objects）。聚合是一个或多个实体的集群，也可能包含值对象，集群的父实体被称为聚合根（Aggregate Root）。
(thedomaindrivendesign.io)
例如，在电子商务领域，你也许会定义一个命名为 Order 的聚合，包含 Address(值对象)和 Consumer(实体)。
实体（Entities）
实体是具有惟一标识符的潜在可变对象，在其域模型中有自己的生命周期，从而我们能够获得该实体完整状态转换历史。
值对象（Value Objects）
值对象与实体的区别在于值对象是不可变的，并且没有唯一的标识，仅由其属性的值所定义。这种不变性造成的结果是，为了更新值对象，必须创建新实例来替换旧实例。
服务（Services）
服务是执行某些逻辑的无状态对象，这些逻辑不适合在单一的实体或值对象上进行操作。
服务执行特定于域的操作，可能会涉及多个域对象。
仓库（Repositories）
仓库主要用于处理存储，抽象了对数据存储的关注，负责持久化聚合。
工程（Factories）
工厂用于在对象的构造中提供抽象，并返回聚合根、实体或值对象。工厂可以替代构造函数构建复杂的对象。
事件（Events）
事件表明领域中已经发生的重大事件，需要向属于该领域的其他利益相关者报告。通常聚合会负责发布事件。
组件（Modules）
开发人员很少提及组件，但是，使用组件可能会非常有趣。
组件帮助我们分离概念，可以根据不同的编程语言将其定义为包（package）或命名空间（namespace），并且始终遵循通用语言（Ubiquitous Language）。
结合以上构建块，战术设计还提供了许多有价值的模式，如 CQRS、事件源（Event Sourcing）、分层架构（Layered Architecture）……，这些模式可以帮助我们构建易于维护和扩展的更好的系统。
References:
[1] https://tech.tamara.co/ddd-in-a-nutshell-3852b0a6155a
