DDD

当组织从整体架构过渡到微服务时，他们面临一个关键的、高风险的问题：我们如何划定服务的边界？ 理论上，微服务应该是松散的、解耦的单元，可以独立开发、部署和扩展。然而，在实践中，许多团队最终构建了一个分布式单体，该系统中的服务紧密耦合，以至于单个业务变更需要同时修改和部署多个服务，从而加剧了网络延迟和部署僵局。 为了避免这个陷阱，软件架构师转向领域驱动设计（DDD）。 DDD 是一种软件开发方法，由 Eric Evans 于 2003 年首次提出，它将代码结构与其所代表的复杂业务领域保持一致。 在本文中，我们将探讨 DDD 如何为设计干净、解耦和高度可维护的微服务提供战略和战术蓝图。 1. 战略蓝图：划定服务边界 DDD 分为两个主要阶段：战略设计和战术设计。战略设计是关于对业务环境进行建模并定义服务边界。它提供了架构的“宏观”视图。 A. 无处不在的语言 在企业内部，不同的部门使用相同的词语来表示完全不同的事物。例如： 对于 销售团队，“用户”是潜在客户或潜在客户。 对于安全团队来说，“用户”是一组登录凭据。 对于运输团队来说，“用户”是实际收件人地址。 尝试为“用户”构建一个满足每个人需求的单一、统一的数据库模型会导致庞大、混乱的代码库。 DDD 通过建立通用语言来解决这个问题，这是一种由业务领域专家和开发人员在特定边界内定义和使用的共享词汇表。 B. 有界上下文 有界上下文是领域模型应用的显式边界。在边界内，通用语言中的所有术语都具有单一的、明确的含义。 我们不是使用单个“用户”模型，而是在各自的限界上下文中定义单独的模型： 在订单上下文中，我们有一个包含客户联系信息的 Order 模型。 在身份上下文中，我们有一个 Credentials 模型。 在 Shipping Context 中，我们有一个 DeliveryAddress 模型。 微服务的黄金法则：一个有界上下文直接映射到一个微服务。 通过将系统划分为限界上下文，我们确保微服务松散耦合并代表不同的业务功能。 C. 上下文映射：服务如何通信 有界上下文并不是孤立存在的；他们必须互动。 上下文映射定义了上下文之间的关系和转换机制。关键模式包括：