问将两个应用程序合并为一个

EN

我在这里看到两个截然不同的问题：

1. 合并的功能有意义吗？
2. 将两个应用程序转换为一个应用程序的工作是否通过成本/效益分析？

第一个问题应该是纯用户驱动的。用户将这两组功能组合在一起是否有意义？他们中的一些人是否希望看到粒度较小的视图，然后切换到更详细的视图？诸若此类。

第二个问题是有关实际的发展工作。这可能是一项巨大的工作，却没有什么好处。或者，如果组合的应用程序将来更简单、更易于维护，那么它甚至可以节省整个工作。解决安全问题的开发工作也应被视为这一工作的一部分(不太可能存在任何无法克服的安全问题，但要使联合应用程序安全可能需要做大量工作)。

我们没有信息来回答这两个问题，但在决定如何回应你的老板时，你最好把它们分开考虑。

如果您认为合并后的软件不符合#1，您的反应可能会像我担心的那样，这将不能满足我们的用户/客户的需求，原因如下：这不是反对工作量，而是最终产品不是一个理想的目标。

如果你在抽象中看到了合并应用程序的好处，但认为它的工作量太大，我认为最好的反应不是说“我们不应该这么做”，而是试着给出一个项目将花费多少精力的估计。最终取决于你的老板来决定成本/收益，但是你可以提供信息来帮助解决这个问题(并突出显示任务的大小)。

同样重要的是为什么你的老板要你这么做。如果你不知道，你应该试着找出更多的原因。也许有一个很好的理由，你没有意识到。或者，也许原因不是很好，但它会帮助你有一个更明智的反应。

我的观点是，这取决于您对“应用程序”的定义。

假设您有以下n层结构：

• 数据库A
• 数据库B
• Web服务A
• Web服务B
• 应用程序C

其中A是你的客户面对的东西，B是低水平的监控。

因此，我们在所有层都是分开的，直到我们到达应用程序C，它将服务A和B合并起来，创建一个组合的工具。我认为这是好的和‘正确’的设计。我们在业务逻辑上仍然有完全的关注点，但是我们通过一个网站或应用程序或者其他任何东西向用户展示。

我注意到你的问题“数据库设计”--这使我认为你的结构可能更像是

• 数据库C
  • 表A
  • 表B

• 应用程序C

我认为这确实会导致一个问题，因为对于这两组操作来说，对象和业务逻辑没有明确的分离。危险在于，这些问题被混淆在一起，在一次中断中发生变化，或者在另一次冲突中暴露安全问题。

然而，一个非开发者使用的应用程序C，知道区别吗？还是仅仅是一个“实现细节”？