问如何与另一个有限制的上下文w/o REST保持联系？
EN

Software Engineering用户

提问于 2018-07-26 00:45:14

回答 2查看 2.1K关注 0票数 4

问题：

如果我必须从另一个有界的上下文中获取一个实体，以便将它映射到这个有界上下文中的某个东西，我将如何去做呢？
我是否调用了外部有界上下文的应用层？也许我需要一个新的“查询”应用层来进行这样的查询？
我是否称之为外部有界上下文的存储库？
我是否直接调用外部有界上下文的域模型？

Domain模型(请注意两个独立的有界上下文)：

CustomerContext.Customer -这是完整的客户模型。
ConsentContext.Person -- CustomerContext.Customer的多个实例的缩小、重转换版本.指导此转换的规则驻留在ConsentContext.Person中。Person从不直接引用·Customer``，这里没有依赖项。
请注意:这两个实体绝对属于独立的有界上下文。客户是企业日常工作的基础。由于法律和商业要求，同意人有很大的转变，而且结构完全不同。客户只是一个数据源，所以Person可以使用内部业务逻辑来创建自己。

Application层：

ConsentContext.ApplicationService -实现用例。作为这些用例的一部分，它通过一些ConsentContext.Person获取PersonRepository。

Repos：

ConsentContext.PersonRepository必须与CustomerContext取得联系，检索CustomerContext.Customer并映射到新的人。这就是我要说的话--我从这里开始叫什么？CustomerContext's应用层？CustomerContext's存储库？CustomerContext‘D37域模型？

其他：

这两个有界的上下文运行在同一个进程中，我不使用REST。
我的目标是客户/供应商关系。

architecture

domain-driven-design

回答 2

Software Engineering用户

回答已采纳

发布于 2018-07-28 02:14:53

我将回避关于是否真的存在两个有界上下文的讨论，并讨论它们如何共享数据的问题。然而，在这样做之前，我必须指出，在同一个过程中有两个有界的上下文，这对自己是有害的。从微软的定义

有界上下文是自主的组件，有它们自己的域模型和自己的无处不在的语言。它们在运行时不应该相互依赖，并且应该能够在隔离状态下运行。但是，它们是同一个整体系统的一部分，确实需要相互交换数据。

有界上下文的一个很大的优点是它们彼此独立。如果其中一个倒下，另一个应该能够生存并能够继续运作。如果应用程序比预期更受欢迎，这也有助于实现可伸缩性，允许在不同的服务器上部署。

注意，两个进程空间并不意味着两个服务器。它们可以共享相同的硬件，但它们之间应该尽可能少耦合，这意味着代码中没有耦合。

关于耦合的想法，我们从Eric Evans那里得到了这个

有界上下文之间的代码重用是一个需要避免的危险。

上述所有选项都违反了本指南。

因此，您的问题与Microsoft定义的有界上下文的最后一句有关。这些是你的选择，按优先顺序排列

每个上下文都可以从其他上下文中缓存需要的信息。这是通过所有上下文共享的事件队列或消息队列完成的，当重要的聚合发生变化时，它们会通知其他感兴趣的上下文。朱莉·勒曼( Julie )对此进行了很好的讨论，这里。如果您想坚持使用单个硬件，消息队列也可以在该硬件上运行，尽管这会带来一些可伸缩性和持久性问题。

第二个选项是添加一个API。我知道您说您没有API，但是API可以作为上下文的一部分来部署，所以它们很少是额外的工作。还可以使用CORS规则将它们锁定为只接受来自本地主机的请求。

第三个选项是共享数据库，但是现在我们将上下文耦合起来，因此这是一条危险的道路。如果必须这样做，那么至少要将表放在单独的模式中，这样开发人员才知道他们正在打破上下文之间的隔阂。

我会避免你列出的所有三个选项。不难想象，在一种与另一种环境中的规则发生冲突的情况下，需求会发生变化。毕竟，这就是为什么首先将它们分成不同的上下文。

票数 6