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