问题标签 [bounded-contexts]

我将我的系统分成（至少）两个有界上下文：研究设计和调查计划。

在研究设计上下文中有一个名为“主题”（面试的潜在主题）的概念。我们还保持该领域的受试者和人群之间的关联。

现在，在调查计划中，我们还需要关于对象的（一些）信息（例如：用于计划访问，甚至用于预期的问卷选择，以防事先知道对象所属的人群）。

所以，我在这两种情况下都需要那个“主题”。

我应该选择什么方法？拥有共享内核，如 Eric Evans DDD 书中所述？我不介意（至少现在）让两个上下文共享同一个数据库。

或者......我应该去纯微服务吗？含义：这两个不能/不应该共享数据库...，在这种情况下，我可能不得不通过事件传递走镜像/复制路线：https ://www.infoq.com/news/2014/11 /共享数据有界上下文

对于上述情况，有什么想法更好吗？

谢谢！

这个问题是相关的，但比这个问题更具体。

我将在这里使用一个简单的例子。假设我们User在一个上下文中有一个Customer实体，在另一个上下文中有一个实体。这是同一实体的两种不同表示。

假设User和Customer都有一个电子邮件地址，但电子邮件地址总是通过User所属的有界上下文更改。因此，用户上下文是电子邮件地址的真实来源。所以理想情况下，我希望上下文中的电子邮件地址从客户上下文的角度来看Customer是不可变的。

因此，当在用户上下文中更改电子邮件地址时，EmailAddressChanged会发出一个事件。这可以; 我订阅了Customer上下文中的事件。但是，我现在需要通过更改Customer电子邮件地址来处理此事件。所以我需要某种命令方法来进行这种改变。

User除了从上下文处理事件时，如何确保不使用命令方法？

如果我在两种情况下都允许突变，那么它们都会成为事实的来源，我需要将事件和处理程序的数量增加一倍，以确保信息在两种情况下保持一致

我目前正在研究一个由几个有界上下文组成的 DDD 系统。其中2个是：

1. 上下文“账户管理”：只允许工作人员在这里工作。这个想法是管理客户帐户（如地址、电话号码、联系人等）并验证客户的帐户（基本上检查客户提供的数据是否有效）。
2. 上下文“网站”：我可以作为客户登录并编辑我的数据（例如更改我的地址）

这是问题：

根据定义，登录到帐户管理上下文的用户是员工。所以我可以假设这里所做的更改在“数据已验证”的意义上是“值得信赖的”。appservice 的简化变体如下所示：

这是我在员工更改地址时调用的 appservice。请注意，我没有注入/使用 IdentityService 来了解员工是谁，因为这在这里并不有趣。Account 实体在成功调用其 changeAddress() 方法后会发出一个 AccountAddressChanged 事件，如下所示

但是，一旦客户在网站上编辑数据，我还需要反映更改。我计划通过“AccountAddressChangedViaWebsite”事件来异步执行此操作。帐户管理上下文将订阅并处理该事件，将相应的帐户再次设置为“未验证”。因此，帐户管理上下文的简化订阅者可能如下所示：

现在的问题是：员工直接调用应用服务，客户通过订阅者。如果我们说“我们必须在客户更新他的数据后重新验证一个帐户”，这听起来像是一个域概念。领域概念适合实体或领域服务，但不适合我所知道的应用程序服务或订阅者。这对我来说意味着应该避免以下情况（注意最后一行调用 unverifyAccount()）：

这是有点隐藏在订阅者中的域逻辑，这看起来很奇怪。我有直觉认为这应该是域服务的责任，但是域服务如何知道它是由外部事件（通过订阅者）或命令调用的？

我可以传递一种“发起者”ValueObject，它告诉我造成这种情况的用户是员工还是外部系统。例子：

在这里，我将要做的事情委托给域服务。但是将 OriginatorService 双重分派到 Account 实体是否是一个好的解决方案？这样，实体可以通过询问传入的 originatorService 来检查是谁导致了更改，并且可以取消验证自己。

我想我会在这里陷入 DDD 兔子洞，但是在这种情况下，您的经验/最佳实践是什么？

我需要在系统中注册用户。没有角色，用户就无法存在（如果没有登录名和密码，他肯定无法存在）。管理员应该能够通过选择角色、写入登录名/密码和一些用户信息来添加新用户。登录/密码/安全问题被实现为单独的应用程序/BC（身份验证上下文），角色和权限在授权上下文中，用户信息在单独的帐户管理上下文中。如果所有这些上下文理论上都可以部署在不同的机器上，我该如何实现用户注册过程？现在我正在使用应用程序接口，该接口使用基础设施服务实现以同步和原子方式将所有需要的命令发送到不同的 BC（目前它是同一个大应用程序）。

我有一个关于领域驱动设计的问题。在我的应用程序的用户帐户/个人资料有界上下文中，有一个用户实体，其中包含帐户信息（id、用户名、密码、电子邮件、盐等）和个人资料信息（全名、头像、生日、性别等）。我还有另一个工作职位/申请的有界上下文，其中每个工作职位都有一个雇主用户，每个工作申请都有一个申请人用户。

问题是，工作有界上下文中的雇主/申请人用户是否应该与我用于用户帐户有界上下文的用户实体相同？或者我应该为雇主和申请人设计不同的用户类型实体？

如您所见，只有来自帐户有界上下文的 id、全名、电子邮件和头像等信息与工作有界上下文相关。如果雇主/申请人与帐户/用户配置文件中的用户实体相同，它将加载更多无用的数据（不需要知道雇主/申请人的用户密码）。但是，如果我为它们创建不同的实体类，这将使数据持久化更加棘手，因为在不同实体类中所做的更改可能会更改同一个数据库表中的相同数据。

你怎么看？我应该为所有用户实体使用一个用户实体，还是为不同的有界上下文/聚合使用不同的用户实体？如果后者是可取的，我该如何处理数据/实体持久性？

我听说过关于使用 DDD 的有界上下文来评估微服务的分配。任何想法这实际上意味着什么？

谢谢山羊

我们在当前项目中使用 DDD 实践。我们的问题是我们有很多有界上下文，每个上下文都是包含其持久层的分层架构。问题是，例如在有界上下文中，我们需要从其他有界上下文中引用数据，例如IdentityAccess上下文是负责管理用户的上下文，因此它包含UserModel但我们需要在另一个有界上下文中引用用户因此，我们创建了一个SubscriberUserModel，其中包含来自该有界上下文中用户模型的子集信息。我们有一个迁移项目它包含来自我们所有有界上下文的所有模型，这些模型用于管理迁移和我们的数据库，但我们面临一个问题。我们不能拥有多个引用同一个表的实体我的问题是如何以智能方式处理此问题这是我们尝试生成新迁移时的 EF 异常

我正在实现有界上下文之间的交互，我发现它“以某种方式”削弱了开放封闭原则，我不确定这是设计 BC 和要考虑的常见权衡的自然结果还是我的设计失败。

考虑 Shop BC，您可以在其中使用一些商品从购物车中创建订单。创建的订单由OrderItems 组成，它们中的每一个都包含各种类型的ItemSpecification值对象接口中的一种，例如ProductSpecificationor FooServiceSpecification，保护不变量并包含一些数据。创建 Order 时，会发出任何其他 BC 可以侦听的异步事件。

该异步事件是从 Order 中创建的，并表示为（序列化的）OrderCreatedEvent 对象，包含 OrderDTO 对象，全部放置在与每个 BC 共享的 Core 命名空间中，因此任何 BC 都可以依赖 Core，但不能依赖其他方式。到目前为止一切都很好，几乎：

该 OrderItemDTO 必须包含 interface ItemSpecificationDTO，需要为每种类型的规范实现。我的ItemSpecificationVO（与任何其他 VO/Entity in Order 一样）具有toCoreDTO()实用地实现简单翻译的方法，并且它也使得实现新的相对困难ItemSpecification并且忘记根据 DTO 实现。那应该没问题。

但是听那个事件的其他 BC 呢？在每个 BC 中，该事件需要在其反腐败层中进行转换，并且 BC 可能只对某些类型感兴趣ItemSpecificationDTO并将它们转换为各种值对象，这对于特定的 BC 很重要。

正如鲍勃叔叔所说的关于 OCP 的机智：

您应该能够扩展系统的行为而无需修改该系统。

但是当我实现新类型时ItemSpecification，对于每个可能对这种新类型感兴趣的 BC，我需要专门从 CoreDTO 翻译那个新类型（好吧，我可以编写一些抽象来在每个 BC 中进行翻译，所以我仍然只是添加代码而不修改任何东西，比如添加 if($x instanceof X))。但是，通过添加新类型，ItemSpecification我需要在其他 BC 中进行适当的扩展（甚至可能修改某些内容，因为我们并不生活在理想世界中）。

我不知道该怎么想。这是整个 DDD 方法的缺点吗？或者也许确实是功能，因为在其他 BC 中寻找需要进一步扩展的内容、地点和方式是由领域需求而不是技术问题驱动的？似乎是对的。最后，我正在尝试进行领域驱动设计:-) 但在我看来这也有点危险。恐怕有一天我们会忘记更新其他 BC 并发生一些不好的事情。但这可能是因为我也扮演着领域专家的角色，“恐惧”应该属于这个角色。我的问题只是坐在两把椅子上还是我做错了什么？:-)

I am currently building a microservices-based application developed with the mean stack and am running into several situations where I need to share models between bounded contexts.

As an example, I have a User service that handles the registration process as well as login(generate jwt), logout, etc. I also have an File service which handles the uploading of profile pics and other images the user happens to upload. Additionally, I have an Friends service that keeps track of the associations between members.

Currently, I am adding the guid of the user from the user table used by the User service as well as the first, middle and last name fields to the File table and the Friend table. This way I can query for these fields whenever I need them in the other services(Friend and File) without needing to make any rest calls to get the information every time it is queried.

Here is the caveat:

The downside seems to be that I have to, I chose seneca with rabbitmq, notify the File and Friend tables whenever a user updates their information from the User table.

1) Should I be worried about the services getting too chatty?

2) Could this lead to any performance issues, if alot of updates take place over an hour, let's say?

3) in trying to isolate boundaries, I just am not seeing another way of pulling this off. What is the recommended approach to solving this issue and am I on the right track?

我正在使用域驱动设计实现一个社交网络。我设计了包含用户 ID、用户名、个人资料图片等的配置文件上下文……在这种情况下，用户可以更改他的用户名我还有一个消息传递上下文，用于在用户之间发送消息，在这种情况下我有一个包含 userID 和 userName 的 User 类，注意 User 在聚合中。问题是用户名可以在配置文件上下文中随时更改，这就是我选择不将消息类与用户类绑定的原因，否则我会收到带有旧用户名的旧消息。有没有一种方法，所以我每次都可以通过询问 Profile 上下文来让用户懒洋洋地进入消息传递上下文，如果是，那么在聚合中使用查询是否很好？