在DDD中组成几个有界上下文 [英] Composing several bounded contexts in DDD
问题描述
我们正在开发一个综合的领域模型，该模型包含跨越多个团队的7(！)模型/有界上下文.我们尚未决定每个BC是否完全与其他BC断开连接(由上一层进行协调)，或者它们是否将通过域事件进行通信.
出于所有目的，正在开发的应用程序都是SWT/Swing单线程应用程序，因此不需要在不同的BC之间进行复杂的分布式Mumbo巨型存储.
但是，仍然存在一个大问题:如何整合所有这些不同的模型?是应该由应用层来承担这项任务吗?如果是这样，并且由于在某些情况下(希望很少)，接线和订购最终会变得很复杂，那么应用层不是这样做的错误地方吗?
例如，考虑使用组装非常复杂的人工合成的人(AssembleHumanoid)的情况.我们已经将循环系统，骨骼结构，神经系统，通风系统，协调系统，免疫系统和精神系统以及传感器系统的上下文限制了(大声笑，这一切都是您可能想像的).
在应用程序层中连接所有东西感觉有点不对劲.显而易见的解决方案似乎是仅针对业务流程问题创建第二域层.我抬起头来，但Vernon的实现域驱动设计并没有直接解决问题(尽管他接近@ p531，构成多个有界上下文").
您对此事有何看法?
我现在正在解决与您相同的问题.我在我的项目中的角色是建筑师，我们确定了公元前5年.但是我们是一个团队，打算在一个大型应用程序中开发这些BC.因此，我们的BC是大型保险应用程序中的模块，每个BC都使用自己的通用语言(条约，再保险，安全性，医疗风险评估，保费). 但是我已经给出了很多想法，我想我们将通过Domain Events将更新发送给其他BC.我们的客户是一个MVC站点，它将占用我们的服务层.但是我的意图是，应用程序层具有这种粒度，因此它将设法为客户端执行主要任务，而不会让客户端MVC项目与其他BC协调.
我们在BC之间使用一些共享的内核，但不进行通信.我们确实使用DDD集成模式，其中我们通过Value Objects引用了其他BC.我们也有som BC扮演Factory的角色，例如Security BC正在为其他BC创建不同的用户角色.
但是，当涉及到实际需要执行其他BC中的某些最终任务的用例时，Domain Event就可以解决.
We're developing a comprehensive domain model encompassing 7(!) models/bounded contexts spanning several teams. We are yet to decide whether each one of the BCs is entirely disconnected from the others (being orchestrated by a layer above) or whether they are going to communicate via domain-events.
The application under development is for all purposes a SWT/Swing single-threaded application, so no fancy distributed mumbo jumbo between the different BCs is needed.
Yet, a big question remains: how to integrate all those different models? Should it be the Application Layer to undertake the task? If yes, and since in some (hopefully, few) cases the wiring and order ends up being complex, isn't the Application Layer the wrong place to do that?
For instance, consider the use of case of assembling a very complex synthetically created human (AssembleHumanoid). We have bounded contexts relating to the circulatory system, to the bone structure, the nervous system, ventilation system, coordination, immunological and mental systems and still the sensor system (lol, this was just all made up as you might imagine).
Wiring up all that stuff in the Application Layer feels kinda wrong. The obvious solution seems to be to create a 2nd Domain Layer just for orchestration matters. I've looked up but Vernon's Implementing Domain-Driven Design doesn't directly touch the issue (although he gets near @ p531, "Composing Multiple Bounded Contexts").
What are your thoughts on the matter?
I'm right now tackling the same questions as you. My role in my project is architect and we have identified 5 BC's. But we are one team and intend to develop theses BC's within one large application. So our BC's are modules within a larger insurance application where each BC speaks its own ubiquitous language (Treaty, Reinsurance, security, medical risk assessment, premium). But I have given this a lot of thoughts and I think we'll send updates to other BC through Domain Events. Our client is a MVC site that will consume our service layer. But My intention is that application layer have that kind of granularity so it will manage to perform the main task for the client without letting the client MVC project to coordination to other BC's.
We uses some shared Kernel between BC's but not for communicating. We do use DDD integration pattern where we have reference to other BC through Value Objects. We also have som BC to act like Factory, for example Security BC are creating different user roles for other BC's.
But when it comes to execution of a use case that actually need to to some final task in other BC's , Domain Event comes to rescue.
这篇关于在DDD中组成几个有界上下文的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
