在文中，Hughson提出：
我相信，如果无法正确地构建单体应用（Monolith），那么这时试图强制采用分布式架构进行模块化，这实际上可能会导致损害。
事实上，对此问题InfoQ曾在2014年进行过一次讨论，其中Brown和Hughson探讨了微服务以及“大杂烩”（Big Ball of Mud）这一比喻。当时Brown给出了这样的说法：
如果你正在构建的单体应用系统已成了一个大杂烩，或许你应该思考一下，你是否对软件架构给予了足够的关注？你是否真正地理解了什么是软件中的核心结构抽象？软件的接口和职责是否清晰？如果你没有做到这些，那么为什么认为如果能迁移到微服务架构就会有所裨益？当然，对服务做物理分隔会强制性地规避一些捷径。但是在单体应用中，也可以实现同样的组件间分隔。
Hughson将使用微服务做构建比作为冰山，一眼看上去所显现出来的部分，要远小于位于水下的部分：
如果一个开发团队不能或是不愿意去遵循设计的指导原则（例如，模块化需求），这时额外地添加复杂性可能并非是所需的解决方案。将应用分布化，会使应用更不易于“意外地”纠缠于各种关注中，但并不会杜绝该问题的发生。
Gene借助于Brown的另一篇推文对最后一点做了说明：
Hughson进而返回到对开发团队不能或是不愿意遵循设计指导原则的评论上，他继续指出：
我的观点是，增加“意外地”破坏模块化的困难度并不会解决前面提及的两组人员所面对的问题，即不能遵循设计指导原则的开发团队，以及不愿意遵循设计指导原则的开发团队。这颇具讽刺意味，那些并没有理解模块化必要性的人，可能无论各种障碍都会在他们的“解决方案”中颇具创造性。同理，对那些不愿意采用模块化的人同样适用。
Hughson提出，分布式（微服务天生就是分布式的）作为一种实现模块化的手段，并不适用于目标。他认为，关注不应局限于应用架构上，也应同样地适用于应用数据。
一个具有纪律的单体应用团队，可以在单体应用数据架构中维护模块化。而试图共享一个单体应用数据架构的多个独立团队，可能会遇到严重的治理开销问题，也可能会完全地破坏模块化。
Christian Posta在去年就指出了为什么应用中的数据管理会成为迁移到微服务时的最难部分。InfoQ当时就对此进行了报道：
要对一个相当复杂的企业领域构建微服务，我们需要找到该领域中不同职责间的界限。在每个界限上创建一个针对该职责设计的、并表示了该职责的领域模型。进而，每个界限的数据模型被同一界限的领域模型所驱动。使用DDD就可以发现这些界限，并对每个界限创建一个“受限场景”（bounded context），这样每个场景可转变为一个微服务。
该文章的一条评论指出，这可能会需要一定形式的治理。对此，Hughson持赞同态度：
消极措施不足以解决问题，无论是结构性的（“让我们将组件分布化，以免人们破坏模块性”）还是过程性的（例如，“要有纪律”）。治理在应用层（在我看来，即应用架构原则）及以上层是完全有必要的，它有助于实现对竞争利益的协调，并监督设计以免在黑暗的小巷中徘徊。请记住，这可能是由于误解、缺乏经验、不符合规范甚至设计不一致而导致的。需要有人监控所发生的情况，以及同样重要的发生原因。
总而言之，在Hughson看来，构建需要独立管理、扩展和部署组件的应用时，微服务的确可以发挥自身的作用。理解到这一点是很重要的。但是，也需要很好地理解为什么要选取沿微服务这条路走下去。
本文转自d1net（转载）
