架构思考 （六）

使用战术 DDD 设计微服务

在域驱动设计 （DDD） 的战略阶段，您正在绘制业务域并为域模型定义有界上下文。战术 DDD 是指更精确地定义域模型。战术模式在单个有界上下文中应用。在微服务架构中，我们对实体和聚合模式特别感兴趣。应用这些模式将帮助我们确定应用程序中服务的自然边界（请参阅本系列的下一篇文章）。作为一般原则，微服务不应小于聚合，也不应大于有界上下文。首先，我们将回顾战术模式。然后，我们将它们应用于无人机交付应用程序中的运输边界上下文。

战术模式概述

本节提供战术 DDD 模式的简要摘要，因此，如果您已经熟悉 DDD，则可以跳过本节。这些模式在 Eric Evans 的书的第 5–6 章和沃恩·弗农的《实现领域驱动设计》中有更详细的描述。

实体。实体是具有随时间推移而持续存在的唯一标识的对象。例如，在银行应用程序中，客户和帐户将是实体。

• 实体在系统中具有唯一标识符，可用于查找或检索实体。这并不意味着标识符始终直接向用户公开。它可以是 GUID 或数据库中的主键。
• 标识可以跨越多个有界上下文，并且可能持续到应用程序的生存期之后。例如，银行帐号或政府颁发的 ID 与特定应用程序的生存期无关。
• 实体的属性可能会随时间而变化。例如，一个人的姓名或地址可能会更改，但他们仍然是同一个人。
• 实体可以保存对其他实体的引用。

值对象。值对象没有标识。它仅由其属性的值定