有限的上下文和基础架构关系
基于我对DDD的理解，理想的服务是围绕有限上下文定义的。这些服务之间的互动与各自有限上下文的关系反映了。
诸如服务是否应该直接与服务的API相互作用，或者是否应该仅订阅事件主题，等等。
我的问题是这些消息传递组件属于哪些有限上下文？ （甚至其他基础设施作品，例如队列，负载平衡器等）
这是我的关注点，因为我们高度注意应用程序基础架构如何相互依赖。例如，我们试图避免情况，其中两个单独有限上下文的2个基础架构具有圆形依赖性。
Based on my understanding of ddd, services are ideally defined around bounded contexts. And interaction between these services are mirrored with the relationship of their respective bounded contexts.
Things like, should a service interact directly to an api of a service, or whether it should just subscribe to an event topic, etc.
My question is which bounded context does these messaging components belong to? (Or even other infrastructure pieces like queues, load balancers, etc)
This is a concern to me since we are highly watchful of how application infrastructure stacks are dependent to one another. For example, we try to avoid situations wherein 2 infrastructure stacks of separate bounded contexts have circular dependencies.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
长话短说，这取决于
DDD的一个很酷的工具是上下文映射可以帮助您。
在这些情况下，通常可以找到上游和下游有限上下文的关系。
我会尝试描述它，但是对主题进行研究将为您提供更多详细信息。
如果您有2个有限的上下文集成，上游服务是指导合同的服务，因此上游服务的更改将需要更改为下游。
为了回答您的问题，队列应成为BC定义操作的一部分，因此，如果消息合同就像BC B所定义的事件，则可以是其中的一部分，否则，如果它是BC A定义的某种命令应该在那一边。
在我的愿景中，如果您能够负担一个适当的团队来处理所有BC的基础架构，则每个排队，DBS的每个实例，以及一切都将始终是特定BC的一部分，这也可以帮助他们负责他们的团队以分手他们的配置/脚本是为了理解如何对其进行分区和分类时进行管理。
Long story short, it depends.
A cool tool of DDD is the context mapping that can help you.
In these situations, usually, a relationship of upstream and downstream bounded contexts can be found.
I will try to describe it, but doing your research about the topic will give you more details.
In case you have 2 bounded context integrating, the upstream service is the one that guide the contract, so changes to the upstream service will require a change into the downstream one.
To respond to your question, the queue should be part of the BC defining the operation, so if the message contract is like an event defined by BC B it can be part of it, otherwise if it is some kind of command defined by BC A it should be on that side.
In my vision, also if you can afford a proper team handling the infrastructure for all the BCs, each instance of queues, dbs and everything will always be part of a specific BC, and this could help also the team in charge of them to split their configuration/scripts to manage them in understanding how to partition and categorize them.
通常，像这样的组件最好地将其视为上下文之间，而不是任何特定上下文的一部分。由于有限的上下文是一个域级概念，因此基础结构不必被视为任何有限上下文的一部分。
在诸如PubSub主题（而不是管理此类主题的基础架构）之类的特殊情况下，在恰好有一个上下文中，该主题将这种主题宣布为该上下文的一部分，这可能是有用的。上下文（或它们的反腐败层，可以说是在上下文之间存在）可能取决于主题。
In general, components like those are best thought of as between contexts and not part of any particular context. Because a bounded context is a domain-level concept, infrastructure need not be considered part of any bounded context.
In the particular case of things like pubsub topics (as opposed to the infrastructure managing such topics), it may be useful in cases where there's exactly one context which publishes to the topic to declare such a topic to be part of that context, though other contexts (or their anti-corruption layers, which arguably exist between contexts) may depend on the topic.
我认为它应该属于决定合同的卑诗省。例如，将其与上游开放的主机服务进行比较
I think it should belong to the BC that dictates the contract. Compare it for instance with an upstream Open Host Service
通用域，可以用作每个有限上下文或每个有限上下文的单独的组件。
generic domain that can be used as a common component for each bounded context or a separate per bounded context.