Architecture 何时合并多个应用程序以简化其数据集成？

短版：

我们有多个团队，每个团队开发多个应用程序。他们需要共享一些数据。我们应该将这些应用程序合并成一个更大的应用程序来简化数据集成，还是应该将它们分开并利用一些数据交换/缓存机制

较长版本：

我们有许多团队，每个团队负责一组应用程序。其中许多应用程序需要共享数据。一种选择是使用异步消息传递来拥有一个记录系统（所有写入都发生在该系统中），并将该数据广播到需要它的任何其他系统。这些系统将把他们需要的数据位存储在只读缓存中（在他们的数据库中）

这种布局的好处是一个系统可以在不影响其他系统的情况下爆炸。它还使各个团队更容易处理各自的应用程序。它使发布计划更容易，导航的代码库更小，等等

另一个选择是确定这些应用共享的数据太多，而来自消息传递/缓存的开销太高。在这种情况下，您可以决定将这三个应用程序合并到一个更大的应用程序中。然后，您将完全消除数据集成问题，因为您将集成移动到应用程序的单个模块的服务/事务层。换句话说，MyGiantApp仍然可以被拆分（JAR、应用程序上下文等）为不同的模块，这些模块通过另一个模块的事务服务API相互通信。在我们的例子中，我们会像使用弹簧一样使用弹簧 服务总线，具有方法调用而不是web服务或异步消息传递

虽然第二个选项简化了数据集成，但它使开发复杂化。现在，X个团队必须在相同的代码库上工作。通过使用分支、持续集成和单独的库/上下文等，可以在一定程度上缓解这种情况，但归根结底，这仍然是我们正在构建的一个令人遗憾的工件。而且，现在一个团队的错误可以更容易地传播到整个应用程序；一个应用程序的崩溃可能会让一切都崩溃

---

您将如何决定何时使用解决方案1以及何时使用解决方案2？

您是否考虑过并发、事务

我不知道您的要求，但感觉是时候以正确的方式解决这个问题，并使用一个中央“存储库”来管理您的共享数据了。

嗨-不确定我是否涵盖了您想要回答的确切问题-但这是一个开始；如果你想澄清，我会相应地更新我的答案

在数据管理方面您可能需要按照以下思路开始思考。首先想到的是，你不想前后矛盾；这将建议您使用一个共享的数据实例——或者您可以拥有多个副本，前提是该数据的管理和保管过程非常清晰

就集成而言，重用取决于各种系统的非功能性需求。单一共享服务使数据管理变得容易（因为只有一个副本需要担心），但这意味着它可能成为瓶颈；此外，“链中最薄弱的一环”规则适用——如果共享服务下降，会产生什么影响

可能的解决方案选项

如果没有更多信息，很难知道推荐什么，但我的想法是：

• 将三个应用程序分开
• 对共享数据使用单个共享服务
• 可以通过“服务”访问共享数据-这将为您提供最多的控制和选择
• 共享服务可能作为单个实例存在，也可能部署了服务的多个实例（但只有一个DB实例）

关键的一点是，你应该能够在不影响其他应用的情况下抽象出共享服务——特别是，你不应该考虑制作一个优步应用

还有一件事——在商业意义上考虑存在一个“服务”并不排除有多种技术上公开和使用它的方法

我把它放在一个单独的答案中，因为它的重点与我的第一个答案完全不同

听起来你已经想清楚了，并且对你的问题和解决方案都有很好的把握。让我再试一下（我认为是）你的关键问题

你会怎么决定

回到基础：从你所知道的事实开始。
与您团队的相关人员一起举办白板研讨会，您需要：

• 起草一份相关约束条件的清单
• 列出您不想要的结果（单个大型不可管理的应用程序等）
• 也建议但可能不是必需的：识别风险和潜在影响（作为约束或不期望结果的一部分）
• 列出您想要的结果（共享数据、轻松部署等）
• 优先考虑想要的和不想要的结果（非常重要），如果它们在辩论过程中发生变化，不要感到惊讶

这些信息应足以开始建立讨论和决策框架

在本次研讨会之前，您还可以做一些额外的事情（或者作为研讨会的一部分，取决于您的政治和社会动态）

• 从“业务”和“架构”的角度确定系统的目标。（提示：两者应该对齐——或者至少不冲突）
• 如果对系统或您的业务有一个明确的愿景，应该会有所帮助（但请记住，这些愿景并不总是存在的，而好的愿景更为罕见）
参考你的系统的商业/战略计划——考虑市场、趋势等。你认为应用程序可能会发生什么？