我已经阅读了很多关于使 ef core + ddd 协同工作的主题，但它们仅展示了我们只有一个微服务的示例。我坚持将 EF Core + DDD 放在不止一个位置的解决方案。例如，我们有 1 个数据库和 2 个微服务（身份、时间表）。在每个服务中，我们都必须保持自己的有界上下文。身份服务仅与用户、角色、...表一起使用...相反，安排服务与用户、约会等一起使用。此外，当我们设计域模型时，我们只使用我们需要的属性。因此，在用户实体的约会服务中，我只需要在身份服务中使用电子邮件、密码等时使用 ID、NameDetails、地址、ContactInfo 等。问题是：我应该为每个微服务使用不同的数据库上下文吗？如果是，在这种情况下我应该如何处理迁移？
【问题讨论】：
标签： asp.net-core entity-framework-core domain-driven-design microservices
我认为在这种特殊情况下，身份服务中的用户与约会服务中的用户不同。我会在约会服务中创建新实体，例如 Person(具有 NameDetails、Address、ContactInfo、DateOfBirth 等属性)，并将其保存在该服务的单独数据库中（2 个数据库 2 个服务）。
【讨论】：
将一个数据库用于两个或多个微服务本身就是矛盾的。微服务应该是自治的，这意味着它不应该与不同的微服务共享同一个数据库。
例如，如果您需要在两个服务中引用 user-id，您将只存储此 id，无论是整数、字符串还是任何其他类型的键。
您的第二个数据库将无法验证该外键是否存在，因为它不知道存储 Users 的表。
当您真正想要使用微服务时，您可能希望为每个服务创建一个单独的 db-context，它拥有自己的迁移和自己的数据库。
如果您仍想使用同一个数据库来执行此操作，您可以创建许多实际上指向同一个数据库的DbContexts，但只定义一组实体。
通常有不同级别的领域驱动设计。您可以在没有微服务甚至没有分布式系统的情况下进行领域驱动设计。 Aggregates、Commands 和 Events、Distributed Systems 等关键字都是 domain-driven-design 的一部分。
一些关于domain-driven-design的阅读资源
https://stackoverflow.com/a/1222488/5397642
https://martinfowler.com/bliki/DDD_Aggregate.html
https://medium.com/withbetterco/using-aggregates-and-factories-in-domain-driven-design-34e0dff220c3
【讨论】：