我已经阅读了很多有关使ef core + ddd协同工作的主题，但是它们仅显示了一个示例，其中我们只有一个微服务。我坚持将EF Core + DDD放在一个以上的解决方案。例如，我们有1个数据库和2个微服务（身份，时间表）。在每项服务中，我们都必须保留自己的受限上下文。身份服务仅与用户，角色，...表一起使用...相反，计划服务与用户，约会等一起使用。此外，在设计域模型时，我们仅使用所需的属性。因此，在用户实体的约会服务中，当我在身份服务中使用电子邮件，密码等时，我仅需要使用例如ID，NameDetails，地址，ContactInfo。问题是：我应该为每个微服务使用不同的数据库上下文吗？如果是，在那种情况下我应该如何处理迁移？
答案 0 :(得分：2)
为两个或多个微服务使用一个数据库本身就是一个矛盾。微服务应该是自治的，这意味着它不应与其他微服务共享同一数据库。
例如，如果您需要在两个服务中引用user-id，则只需存储此ID，无论它是整数，字符串还是任何其他类型的键。
您的第二个数据库将无法验证该外键的存在，因为它不知道存储Users的表。
当您真的想使用微服务时，您想为每个服务创建一个数据库上下文，它具有自己的迁移和数据库。
如果您仍想使用相同的数据库来执行此操作，则可以创建许多实际上指向同一数据库的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
答案 1 :(得分：0)
我认为在这种特殊情况下，身份服务中的用户与约会服务中的用户不同。我会在约会服务中创建一个名为 Person（具有 NameDetails、Address、ContactInfo、DateOfBirth 等属性）的新实体，并将其保存在该服务的单独数据库中（2 个数据库 2 个服务）。