Section 3: 微服务架构与领域驱动设计 (09:36 - 19:58)

在与客户进行深入讨论后，我们决定采用微服务架构。 ⏎ 客户提到，希望应用程式具备高弹性（resilient to failure）、可扩展性（scalable），更快的开发速度，持续部署能力，以及强化的监控和调试能力。微服务架构能够很好地满足这些需求。 ⏎

为了更好地组织和管理我们的微服务，我们将应用领域驱动设计（DDD）。 ⏎ 这意味着我们需要识别应用程式中的不同领域（domains）。让我们来看看如何将我们的应用程式设计分解为不同的领域。 ⏎

现在，让我们来讨论一下数据库设计方面的一些考量。 ⏎ 我们需要特别关注实体之间的关系。例如，客户和订单之间存在关系。在传统的单体应用中，我们可能会直接在订单表中包含客户对象。但是，在微服务架构中，我们采取不同的方式。 ⏎

在微服务架构中，我们只会在订单表中存储客户的 ID，而不会包含完整的客户对象。 ⏎ 同样，在客户表中，我们也不会存储订单列表。如果我们需要获取某个客户的订单列表，我们需要查询订单领域，并根据客户 ID 进行过滤。 ⏎

为了更好地理解这一点，假设我们需要获取特定客户的订单。 ⏎ 我们不会直接在客户领域中查找订单信息，而是向订单领域发送一个 HTTP 请求（或者使用其他同步或异步通信方式），要求订单领域返回所有客户 ID 与指定客户 ID 匹配的订单。 ⏎

对于订单行（order line）和产品（product）之间的关系，我们也采用类似的方式。 ⏎ 订单行表中会包含产品 ID，但不会直接包含产品对象。如果我们需要获取特定产品的订单行信息，我们需要查询订单领域。 ⏎

这种设计方式同样适用于支付领域和通知领域。 ⏎ 通过这种方式，我们将应用程式分解为更小、更独立的领域，从而提高了应用程式的灵活性和可维护性。 ⏎