业务领域有五个高级有界上下文
此外，这些有界的上下文具有诸如订购和交付文件之类的子上下文。尽管该项目由数千个类和数十个EJB组成，但大多数业务逻辑都存在于关系数据库视图和触发器中，原因是：所有业务事务中都涉及许多连接，联合和约束。换句话说，有界上下文之间存在复杂的依赖关系和约束网络，这限制了状态转移。通俗地说：业务规则非常复杂。
现在，如果我将这个monolith拆分为每个服务微服务架构的数据库，有界上下文是建议的服务边界，我将不得不使用显式API调用来实现所有业务逻辑。我最终会有数百个API实现所有这些愚蠢的小业务规则。由于性能是主要因素（我们现在使用很多努力来优化SQL），这是不可能的。其次，隔离的API可能是在这个不断发展的业务规则网络中维护的噩梦，因为数据库触发器实际上支持高内聚和干燥心态，透明地执行业务规则。
我得出结论微服务架构不适合这种类型的文档管理系统。我是正确的，还是从错误的角度接近这个想法？
答案 0 :(得分：5)
首先，您不必拥有微服务架构。我真心的！如果您是由管理层/架构师订购来完成它，并且它没有解决您遇到的任何实际问题，那么您可能正好回过头来。
话虽如此，并且免责声明我不知道您的申请的确切要求，有＆＃34;事情＆＃34;有限的背景是一种气味。因此，将＃34;客户＆＃34;，＆＃34;应用程序＆＃34;，＆＃34;文档＆＃34;等作为服务很可能是错误的做法。
有界上下文不应该是对特定实体的CRUD操作。它们应该完全独立（或尽可能独立）＆＃34;垂直＆＃34;整个应用程序的一部分。最好使用自己的Database 和 GUI。它们也应该彼此独立运作，不需要其他服务的输入来做出自己的决定。
这与以数据为中心的设计完全相反，其中表/字段和关系是核心概念。在这里，功能是核心概念。您必须将应用程序与功能分开才能实现良好的分离。
我可以想象一个文档管理系统具有这些独立的有界上下文/服务：搜索，工作流程，编辑等。
以下是您的想法：搜索不需要任何其他服务的任何（同步）输入。它可能会接收定期的，甚至是近期的新文档更新，但这并不会影响它的主要功能：搜索已编入索引的文档。图形用户界面也是独立的，类似于谷歌一样的页面，可能带有搜索框。它可以独立提供结果，并在您单击结果时链接回工作流或编辑应用程序。
其他人也同样独立。同样，重点是以一种使它们独立工作的方式拆分服务。如果你没有这样做，你只会让微服务更糟糕。
答案 1 :(得分：0)
首先，上述答案是正确的，建议您需要以更好的方式完成微服务。
现在如果您关注可伸缩性（微服务之间的许多api调用）。
我强烈建议您验证在第一级确实需要多少约束，以及您可以以异步方式执行多少约束。我的意思是在分布式环境中，我们实际上不需要同时验证所有的东西。
有时候这些东西不是直接可见的，例如：假设有两个服务订单服务，客户服务和订单服务公开一个api，即为客户ID下订单。而且业务人员说你不能为未知客户下订单
一个实施来自您同时调用客户服务的订单服务----在这种情况下，客户服务停止将影响您的服务，现在让我们确实需要问题。
因为客户只是下了订单并且有人从客户服务中删除了该客户，所以现在我们有一个不属于客户的订单。无法保证一致性。
在新的溶胶中。我们说允许订单服务下订单而不检查客户ID并执行以下操作之一：
使用ProcessManager检查客户有效性并将订单状态更新为无效，并在使用ProcessManager删除客户时将订单状态更新为无效或执行业务逻辑 根本不检查，因为下订单计算了一件事，当这个订单将在发货过程中，服务无论如何都会检查客户状态
通过这种方式，您的API命中率会降低，并且会产生更好的独立服务