我已经阅读了很多关于使 ef core + ddd 协同工作的主题，但它们仅展示了我们只有一个微服务的示例。我坚持将 EF Core + DDD 放在不止一个位置的解决方案。例如，我们有 1 个数据库和 2 个微服务（身份、时间表）。在每个服务中，我们都必须保持自己的有界上下文。身份服务仅与用户、角色、...表一起使用...相反，安排服务与用户、约会等一起使用。此外，当我们设计域模型时，我们只使用我们需要的属性。因此，在用户实体的约会服务中，我只需要在身份服务中使用电子邮件、密码等时使用 ID、NameDetails、地址、ContactInfo 等。问题是：我应该为每个微服务使用不同的数据库上下文吗？如果是，在这种情况下我应该如何处理迁移？
2 回答
3
将一个数据库用于两个或多个微服务本身就是一个矛盾。微服务应该是自治的，这意味着它不应该与不同的微服务共享同一个数据库。
如果您需要user-id在两个服务中引用一个例如，您将只存储此 id，无论是整数、字符串还是任何其他类型的键。
您的第二个数据库将无法验证该外键的存在，因为它不知道Users存储的表。
当您真的想使用微服务时，您可能希望为每个服务创建一个单独的 db-context，它有自己的迁移和自己的数据库。
如果您仍想使用同一个数据库来执行此操作，您可以创建许多实际指向同一个数据库的DbContext ，但只定义一组实体。
一般来说，领域驱动设计有不同的层次。您可以在没有微服务甚至没有分布式系统的情况下进行领域驱动设计。关键字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
于 2019-01-21T15:30:48.940 回答
0
我认为在这种特殊情况下，身份服务中的用户与约会服务中的用户不同。我会在约会服务中创建一个名为的新实体，例如 Person(具有 NameDetails、Address、ContactInfo、DateOfBirth 等属性)，并将其保存在该服务的单独数据库中(2 个数据库 2 个服务)。
于 2021-03-04T21:53:25.500 回答