模块化软件应用体系结构

Question

对于这个问题，让我们假设如下：

• OOP的设计原则正在被遵循。
• 模块通常不会消耗一个以上的通用关注点，而是不同的业务目的。
• 混合应用程序(多平台)。
• 涵盖单一的商业问题。然而，这个单一的业务关注有几个较小的关注点，在技术上可能是他们自己的应用程序。

此应用程序应用作下列问题的“模型”.与标准的“一个巨大的应用程序”相比，遵循微服务体系结构有什么好处或缺点吗？这是否妨碍了不同部分之间有效地共享和交换数据的能力？

Answer 1

阿尔塞尼·莫利延科的回答还不错，但我想他并没有完全回答你的问题。我同意他的观点，即从最终用户的角度来看，特性控制基本上独立于软件产品的内部组件结构。特性控制是IMHO“使用一个大组件”与“使用多个小组件”的错误决策标准。

但是，从软件工程师的角度来看，内部组件结构非常重要。今天的主要共识是，开发许多小的、独立的组成部分，它们大多是相互解耦的，每一个都只有一个责任，比开发一个具有许多责任的庞大而复杂的组成部分要容易得多。正如您已经提到的，这无疑是一种权衡，许多小型组件需要额外的接口，以及在它们之间交换数据(如用户数据或会话信息)的方法。然而，在有利的方面是

• 更好的并行开发(每个组件可以由不同的团队或人员并行开发)
• 更好的可测试性、可维护性和可进化性(每个单独的组件都可以单独测试，这使得编写自动化测试、识别bug的根本原因和管理更改变得更加容易)

当然，没有“银弹”或共识，认为“小”组件应该是什么样子。这在很大程度上取决于系统的总体大小和团队的规模--它们越大，就越需要将系统架构分成更小的组件。

例如，在web服务的世界中，这种讨论导致了微型服务的思想。然而，对于小型产品和单独开发人员来说，这样的架构可能太细了可能会增加太多的额外开销。

我们不知道您的系统和团队有多大，所以只有当您需要许多小组件时才能做出决定(但是，正如我最初所说的，不是基于您需要提供特性控制的事实)。

Answer 2

从技术上讲，这不重要。

看看Netflix。你看到多少种产品？只有一个。然而，Netflix是一个由数十个服务组成的企业集团，这些服务可以使用独立的技术栈独立开发和部署。

现在来看一个随机的SquareSpace网站。然后再选一个。他们可能没有共同之处。两种不同的产品，使用两套不同的功能。尽管如此，底层的编程代码对两者都是一样的。

所以如果问题不是技术性的，它是什么，更重要的是，是谁决定的？

实际的问题是你如何向客户展示你的产品。将一系列特性呈现为单一产品可能是有意义的。或者，将系统表示为多个产品可能更有用。

以微软办公室为例。共享代码(Excel除外)，多个产品。您有PowerPoint，也有Word，这并不是因为技术上不可能将文本编辑器和演示文稿编辑器的功能结合到一个软件产品中，而是因为用户不知道如何使用这类产品(据微软称)。

现在考虑Visual。如果我为服务器应用程序编写C#代码(这就是我所做的一切)，我并不真正关心Visual、F#或C++。我甚至不关心Silverlight、WPF或Windows窗体。尽管如此，这一切都是在Visual中，以某种形式的特性。都在一个地方。有趣的是，它并不总是这样的。在90年代，您必须为不同的语言安装不同的IDE:如果您使用了两种语言，那么您将在计算机上同时安装Microsoft和MicrosoftVisualC++应用程序。

因此，这个决定完全属于市场营销。一旦做出决定，就应该由您来开发软件产品，以确保系统各部分之间有足够的凝聚力，并避免代码重复。