Domain driven design 在两个有界上下文之间放置公共值对象的位置？

我试图在一个小项目中应用领域驱动设计 我想分离其他用户逻辑的身份验证，

---

我使用一个值对象作为id（userID），一开始我的userID与用户处于同一级别（包），但我意识到，当我分离用于身份验证和用户的有界上下文时，它们共享一个用于userID的公共值对象，所以我的问题是我必须将公共或共享值对象放在哪里？如果我创建了一个名为commons的包，这是正确的吗

建议不要在有界上下文之间共享模型，但是，您可以共享ID，甚至是简单的值对象（如

Money

）

一般规则是，您可以共享任何不可变的内容或很少更改且IDs很少更改结构的内容（此处不可变指源代码和值不可变）。

称为“公共”的包通常指您在项目中使用的可重用概念，这样，您就不必在每个项目中编写它们。在那里，通常会放置基本抽象对象和接口，例如实体、值对象等

但这不是关于用户ID的问题。您要说的是将userId放在一个“共享内核”模型中。这是一种选择，但通常不推荐

在我看来：

身份验证BC具有id、登录、密码、角色等概念

用户BC有名字、姓氏、地址、年龄等概念，但它还必须有从auth BC获得的id

据我所知，您有两种选择：

（1） 身份验证BC明确共享“id”概念，即它有一个共享内核。所以“id”概念也属于用户BC模型

---

（2） 身份验证BC是一种通用BC。因此，您必须将用户BC与auth BC集成，才能从中获取id。

首先，我个人认为这是代码级别的上下文映射问题，在代码级别，您实际上希望在多个有界上下文之间拥有一个共享内核

这实际上取决于业务。你通常需要考虑以下问题：

• 负责每个有限上下文的不同团队如何相互协作？如果是一个团队维护所有相关的有界上下文，这可能没问题，但是多个团队有不同的目标，这就引出了下一点
• 您计划如何长期维护这个共享内核？一般来说，这个共享内核需要更改以适应业务变化

---

关于更详细的论点，有很多关于上下文映射的参考资料，比如沃恩·弗农的书《实现域驱动设计》。

很抱歉提出了最后的问题，但这是否意味着在引用创建博客文章的用户id时，我们可以在

Blog\Domain\Model\Post

中使用

Auth\Domain\Model\UserId

值对象？或者我们应该有一个本地

Blog\Domain\Model\UserId

对象吗？如果是以后，我们应该如何保持在Auth上下文的UserId中检查的相同标识符有效性？@KanstantsinK。您可以使用同一个类作为ID。在其他有界上下文中复制每个微小的类并不是那么聪明，只是说您遵循DDD。IDs类似于原语值。通过使用同一个类，您可以使依赖关系显式化，这在一个好的体系结构中始终是必需的？BC意味着将内部和外部的一切隔离开来，并且只通过域事件与其他BC通信。我的意思是BC模型将是一个共享内核。共享内核是由多个BC共享的模型。这是一种整合BCs的方式，一种战略模式，将BCs结合在一起最多，因为它们共享一个模型。除此之外，您的评论：“仅通过域事件与其他BC通信”。。。事实并非如此，事件是一种方式，但不是唯一的方式（例如，它们可以与远程调用通信）。无论如何，不管是事件还是调用，它们都是集成的实现细节，而不是模式。共享内核是集成BCs的一种模式（包括其他模式）。但BCs不应该知道彼此的内部工作吗？因为按照这个定义，共享内核不是DDD意义上的BC。它是一个共享内核，但仅此而已。我同意你说的其余的。我写错了。Auth BC不是一个共享内核。共享内核是BC模型（或只是其中的一部分）。但在这种情况下，BC必须分享它，它不是内在的。这就是为什么它是一个共享（模型）内核。它必须与其他BC共享，否则它将不是一个共享内核。参见沃恩·弗农红皮书《实施DDD》第92页。我将编辑我的答案，使之更加清晰，我不会说整个BC是一个共享内核，这是我的错误。