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

我把它放在一个单独的答案,因为它的重点是相当不同的,我的第一个。

听起来你已经把事情想清楚了,对你的问题和解决办法都有很好的把握。让我再看看你的关键问题。。。

你怎么决定。。。

回到基本点:从你知道的真实开始。

• 列出相关限制条件。
• 列出你不想要的结果(单个大的不可管理的应用程序等)。
• 也建议,但可能不是必要的:确定风险和潜在影响(作为限制或不希望的结果的一部分)。
• 列出您想要的结果(共享数据、轻松部署等)。
• 优先考虑可取和不可取的结果(非常重要),如果它们在辩论过程中发生变化,不要感到惊讶。

这些信息应该足以开始建立一个讨论和决策的框架。

在这个研讨会之前,你还可以做一些额外的事情(或者作为研讨会的一部分,这取决于你所处的政治和社会动态)。

• 从“业务”和“架构”两个方面确定系统的目标。(提示:两者应该一致——或者至少不冲突)。
• 如果对系统或您的业务有明确的愿景 帮助(但请记住,这些并不总是存在的,好的更是罕见)。
• 请参考您所使用的系统的业务/战略计划-并考虑市场、趋势等。您认为未来应用程序可能会发生什么变化?在建筑上超前思考 不是吗 与代码级别的YAGNI相同,对未来的仔细考虑可能会影响您现在所做的决策。

依据 Master Data Management 线。第一个想到的是你不想 Reference Data

依据 集成 重用依赖于各种系统的非功能性需求。单一的共享服务使数据管理变得容易(因为只有一个副本可供担心),但这意味着它可能成为瓶颈;此外,“链中最薄弱的一环”规则也适用——如果共享服务宕机,会产生什么影响?

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

• 将三个应用程序分开。
• 对共享数据使用单个共享服务。
• 对共享数据的访问可以通过一个“服务”-这将给你最多的控制和选择。

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

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

你有没有想过并发,事务。。。

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