界环境的集成本地

在“实施领域驱动设计”，弗农给出详细的例子为与消息整合为界上下文或基于REST的解决方案，它也不在话下数据库集成，但我知道这不是一个很干净的解决方案共享数据库或BC之间至少有数据库表。界环境的集成本地

但如果2个的BC我要集成在同一台服务器上本地托管的是什么，是不是真的要使用消息/ REST/RPC的解决方案是一个好主意？（这似乎更适合远程托管BC我）

否则，除了与DB集成，有什么其他的方法？两个BC在相同的过程中，并直接调用它（仍然使用适配器和翻译器进行干净的分离）？

感谢

来源

2016-08-11 Jonathan

如前所述，您可以使用ZeroMQ或（for .NET）MediatR在内存中实现pub-sub。但共享数据意味着扩展所有权，这也意味着您的环境不再受限制。 –

你可以考虑使用类似0MQ进程间通信在同一台服务器上。过去我也只是在你提出的同一个过程中托管东西，并且只是使用接口/内存消息来分离出上下文。

一切都是关于到底取舍，所以你只需要决定你是否愿意接受什么隔离的水平。最简单的解决方案是通过文件夹和界面分开解决方案，另一端是完全独立的服务器。

来源

2016-08-11 19:47:54 tomliversidge

我不认为这个位置应该起作用w.r.t. BC之间的整合。

确实还有其他因素需要考虑，例如保证传递给收件人以确保处理发生。无论这两个BC是否托管在同一台服务器上，都应该这样做。

另一个理由忽视的位置是，当你需要扩展，你的架构应该能够从一开始就处理它。

正如tomliversidge所提到的，它可以使用一些部署机制，如非持久消息传递来加速事情，但肯定会有一个权衡，并且必须是一个有意识的决定。

来源

2016-08-12 06:16:13

好的，谢谢你的回复。但是从一开始就使用“远程集成类型”是否真的很重要，即使我们现在不打算部署在多个服务器上？如果我们正确地做到这一点，我们就不能将现在集成到同一个进程中，这会更快更简单，而且如果我们需要分离进程或服务器，稍后请更改适配器。 – Jonathan

你可以这样做@Jonothan。请记住，您可能会保持一致性，只要您使用的机制可以保证所有更改得到保证，那么您将会保持良好状态。但是，这可能会导致分布式交易甚至跨越两个BC的交易吗？如果是这样的话，稍后可能会遇到一些重大的重构。如果您现在可以放弃实施这个想法并且不需要太多额外的时间或精力，它*可能*值得考虑。不是“面向未来”，只是试图阻止额外的工作向前发展:) –

界环境的集成本地

回答

相关问题