database - 微服务不适合业务领域？

Question

业务领域有五个高级限界上下文

• 客户
• 申请
• 文件
• 决定
• 预制件

此外，这些限界上下文具有子上下文，例如文档的排序和交付。尽管该项目由成千上万个类和数十个 EJB 组成，但大多数业务逻辑都驻留在关系数据库 View 和触发器中，这是有原因的:所有业务事务中都涉及大量连接、联合和约束。换句话说，有界上下文之间存在复杂的依赖关系和约束网络，这限制了状态传输。通俗地说:业务规则非常复杂。

现在，如果我要将这个整体拆分为每个服务微服务架构的数据库，有界上下文是建议的服务边界，我将不得不使用显式 API 调用来实现所有业务逻辑。我最终会得到数百个 API 来实现所有这些愚蠢的小业务规则。由于性能是主要因素(我们用很多努力来优化 SQL，就像现在一样)，这是不可能的。其次，在这个不断发展的业务规则网络中维护隔离的 API 可能是一场噩梦，因为数据库触发器实际上支持高内聚和 DRY 心态，透明地执行业务规则。

我得出的结论是微服务架构不适合这种类型的文档管理系统。我是正确的，还是从错误的角度接近这个想法？

Answer 1

首先，您不必拥有微服务架构。我真心的!如果管理人员/架构师命令这样做，但它并没有解决您遇到的任何实际问题，那么您可能会反对。

话虽这么说，并且免责声明我不知道您的应用程序的确切要求，将“事物”作为限界上下文是一种气味。因此，将“客户”、“应用程序”、“文档”等作为服务很可能是错误的做法。

限界上下文不应该是对特定实体的 CRUD 操作。它们应该是整个应用程序的完全独立(或尽可能独立)的“垂直”部分。最好有自己的数据库和 GUI。它们还应该彼此独立运行，不需要其他服务的输入来做出自己的决定。

它与以数据为中心的设计完全相反，其中表/字段和关系是核心概念。在这里，功能是核心概念。您必须按照功能拆分您的应用程序才能实现良好的分离。

我可以想象一个文档管理系统具有这些独立的限界上下文/服务:搜索、工作流、编辑等。

您可以这样想:搜索 不需要来自任何其他服务的任何(同步)输入。它可能会定期接收新文档的更新，甚至是近期的更新，但这并不影响它的主要功能:搜索已经索引的文档。 GUI 也是独立的，类似于带有搜索框的类似 google 的页面。它可以独立提供结果，并会在您单击结果时链接回工作流或编辑应用。

其他人也同样独立。同样，关键是以一种使它们独立工作的方式拆分服务。如果没有，微服务只会让事情变得更糟。