在我的工作场所（以及许多其他领域），我非常重视围绕服务构建架构。 （我在一家电子商务初创公司工作）。但是，我认为服务隐含地被认为是分布式的。我相信分配的第一定律——“不分配”。所以，我相信我们不应该不必要地使架构复杂化。它应该是一个可以发展的架构。因此，解决该问题的方法之一是创建定义良好的命名空间并围绕它构建代码，但通过 java api 保持通信。 （这使得监控要求低，可靠性/可用性问题低）。这可以很容易地通过将模块包装到 Web 服务中来演变成分布式架构，当规模需求启动时。所以，问题是 - 将代码编写为单个应用程序并演变为分布式服务，而不是直接跳入实现基于 Web 服务的架构有什么缺点？我是否正确假设服务应该暗示设计的基本原则（抽象、封装等），而不是通过网络分发？
【问题讨论】：
分发需要模块化。然而，它需要的不仅仅是模块化：它还需要模块之间的粗粒度交互。
例如，在单流程电子商务系统中，您可能有单独的模块来管理用户的购物车和计算价格。他们可能会通过购物车进行交互，要求计算器为一件商品定价，然后再为另一件商品定价，等等。这非常好。
但是，在分布式系统中，这将需要大量的小方法调用，这是低效的；如果您使用 CORBA 进行分发，您可能会侥幸逃脱，但使用 SOAP，您会遇到麻烦。相反，您可能希望购物车要求计算器一次性为整个订单定价。从关注点分离的角度来看，这可能会更糟（为什么计算器必须知道购物车的概念？），但需要使系统充分运行。
与粒度相关，还有模块通过接口或实现进行交互的问题。使用单个进程，您可以定义一组接口，模块将通过这些接口进行交互；模块可以相互传递实现这些接口的对象，而不必相互告知实现（例如，调度程序模块可以传递任何实现interface Job { void run(); } 的东西）。在整个网络中，对粗粒度的要求意味着传递的任何对象都必须按值传递（因为通过引用传递将需要对传递模块进行细粒度调用 - 除非您使用的是移动代码，但您不是，因为没有人是），这意味着两个模块必须了解并同意对象的实现。
因此，虽然以模块化方式构建单进程系统使以后实现 SOA 更容易，但它并不像将每个模块包装在 SOAP 接口中那样简单。至少，除非您从一开始就以粗粒度的方式构建系统，否则不会如此，这意味着放弃许多可靠且有用的良好软件工程实践。
【讨论】：