问题标签 [bounded-contexts]

在“实施领域驱动设计”中，弗农给出了将有界上下文与基于消息传递或 REST 的解决方案集成的详细示例，它还提到了数据库集成，但我知道共享数据库或至少 db 表之间不是一个非常干净的解决方案公元前。

但是，如果我想集成的 2 个 BC 本地托管在同一台服务器上，那么使用消息传递/rest/rpc 解决方案真的是个好主意吗？（对我来说，这似乎更适合远程托管的 BC）

否则，除了数据库集成，还有什么其他选择？在同一个进程中托管两个 BC 并直接调用它（仍然使用适配器和翻译器进行干净分离）？

谢谢

每次我认为我了解如何识别有界上下文时，我都会意识到水仍然很混浊。所以这里...

我正在开发一个包含以下功能的客户门户：客户、用户、公告、反馈、文档和报销。我们只是在另一个系统的报销批准上放置了一个漂亮的 UI，所以这个很容易看出它是我们集成的另一个 BC。现在与其他人一起，我不确定如何将它们组合在一起。所有这些都属于一个单一的 BC '门户'吗？或者也许有单独的“管理”、“通信”、“文件”BC？

任何想法将不胜感激！

我正在开发一个处理短期课程的应用程序，基本上客户可以注册或预订课程，购买课程所需的书籍或其他材料（杂项）。

用例是：

但是在与领域专家讨论时。

（报名有Registration No.、Order No.供参考以及课程名称、日期、地点）

请注意，我们允许部分付款。

我将Sales Order其视为单独的有界上下文和Registration & Reservation Bounded Context另一个

但是基于跨越边界的用例，这是否意味着应该合并两个上下文？

2个有界上下文可以在它们之间进行上游通信是否被认为是一个坏主意？

例如，订单 BC 将发布事件，库存 BC 将订阅该事件，同时库存 BC 可以发布事件，订单 BC 将订阅

假设我有一个带有 2 个聚合根的“目录”有界上下文。公司和个人。公司有一个子实体“职位”的集合，其中包含一个人的 ID 以及一些额外的价值数据。

都好。

现在我们去添加一个带有聚合根 JobAriticle 的“Article”有界上下文。这需要一个从公司职位映射的联系人值对象。

所以知道你应该只引用聚合根我应该怎么做？假设公司与职位的关系存在不变量，所以我不想拆分汇总。是否可以通过公司和职位 ID 通过反腐败层映射职位？或者我是否需要尝试拆分公司集合。

当一个概念在有界上下文中建模为根实体并在另一个有界上下文中作为子实体（两个 BC 中的相同身份）建模时，是否有任何缺点？

来自 Eric Evans DDD：

根以外的实体具有本地标识，但它只需要在聚合中是唯一的，因为没有任何外部对象可以在根实体的上下文之外看到它。

即使它扮演子实体的角色，这个概念也将具有全球身份。我认为埃文的观点是避免在其聚合之外修改子实体，但在另一个 BC 中不会违反不变量。你怎么看？

我有一个 VS2015 解决方案，其中包含一个 webUI 项目和一个充当域的类库项目。类库仅包含 20 个 EF DB First 生成的类（edmx 模型）以及 20 个作用于这些类的 repo。当我需要更改底层数据库时，我会丢弃 edmx 模型并重新生成它。其中一类是Domain.DbEntities.plc. 我的 webUI 引用了这个域库。

一段时间后，我PlcCommunicator在解决方案中添加了一个额外的项目，它引用了Domain lib并且有一些接受Domain.DbEntities.plc作为参数的方法和一些返回的包装类也使用Domain.DbEntities.plc. 我的 webUI 项目引用了“PlcCommunicator”项目，一切正常。

解决方案越来越大，当我向它添加更多项目时，它们都引用和使用相同的Domain lib. 但是现在我添加了另一个名为的项目PlcMonitoringLogger，我决定创建另一个较小的域，它只是主域的一个子集，它包含 5 个类，这些类也都是 EF DB First 生成的 edmx 类，它们在与Main Domain. 其中一类是PlcMonitoringDomain.DbEntities.plc. （注意与 的区别Domain.DbEntities.plc）

现在我需要我的PlcMonitoringLogger项目来使用该PLCCommunicator项目。但PlcCommunicator适用于Domain.DbEntities.plc并且PlcMonitoringLogger只知道PlcMonitoringDomain.DbEntities.plc. 所以我面临的问题是......我可以更改PlcCommunicator方法的参数以接受plcid 而不是Domain.DbEntities.plc对象，也可以只返回plcid 而不是Domain.DbEntities.plc对象。然而，这是正确的做法吗？有什么陷阱吗？优缺点都有什么？另一种解决方案可能是创建一个base plc class，但这似乎不正确。我想将事物彼此分离，并且创建base类感觉不对。

我读了一些关于有界上下文的东西。但是我不能也不想立即将我现有的项目更改为使用这种设计模式。不是最后一位，因为我还没有这方面的经验，而且对于初学者来说很难。我认为在有界上下文之外使用某些方面的“婴儿步骤”是最好的方法，而不是进行完全重建！

因此，如果有人对此主题有一些想法或有用的话，请回复！

我们的项目是使用 DDD 开发的。我们决定将用户身份转移到单个微服务中，该微服务将用于检查用户身份、颁发和验证令牌。

现在，由于帐户和用户位于解决处理用户和帐户详细信息问题的不同微服务中，我们遇到了一个称为最终一致性的挑战。

我们的问题是，我们是否应该首先在帐户和用户微服务中创建帐户/用户，然后将事件发布到用户身份微服务，反之亦然。

在第一种情况下，我们将立即获得帐户和用户的基本信息，但由于最终的一致性延迟，无法提供令牌，因此没有用户能够登录。

在第二种情况下，用户可以登录，但是当他登录到他的帐户时，由于最终的一致性延迟，将没有可用的帐户信息。对于这种情况，当满足最终一致性时发送确认邮件的解决方法，因此用户可以确认注册和登录。

我想听听反馈，哪种情况更有意义，还有什么我现在看不到的问题吗？

我开始将 node.js 项目迁移到微服务方法，并且不知道应该如何共享数据。这是一个示例，假设我有以下有界上下文：

• 帐户（用于管理用户帐户、权限、登录/注销、配置文件等）
• 图片（用于管理文件上传，例如与给定帐户关联的个人资料图片、图片库等）
• 视频（用于管理视频上传和转码为与给定用户相关的各种格式）

在此示例中，图像和视频似乎对帐户有界上下文或微服务具有自然依赖性。我假设我可以将帐户表复制到图像和视频数据库并仅存储所需的帐户数据，但这在保持一致性等方面似乎是一场噩梦，因为帐户信息经常更新，更不用说是否其他微服务也需要同样的依赖。我可以让所有三个微服务都使用同一个数据库，但这违反了每个微服务都绑定到自己的数据库的建议。

处理这种情况的推荐方法是什么？我仍处于计划阶段，并希望确保我以正确的方式做到了这一点。

我应该将我的身份访问（身份验证和授权）放在共享内核中还是创建一个单独的有界上下文，例如：- IdentityAccess

1. 如果我将身份访问权限放在共享内核中，那么共享内核将变得臃肿。共享内核应包含 BaseEntity 或 BasicValueObject 等基本合约，以简化开发过程
2. 如果我选择在不同的有界上下文中进行身份访问，那么其他有界上下文将如何应用权限

请记住，身份访问将包含许多功能，例如用户登录和权限管理（创建用户、规则和组）