在文中，Hughson提出：
我相信，如果無法正確地構建單體應用（Monolith），那么這時試圖強制采用分布式架構進行模塊化，這實際上可能會導致損害。
事實上，對此問題InfoQ曾在2014年進行過一次討論，其中Brown和Hughson探討了微服務以及“大雜燴”（Big Ball of Mud）這一比喻。當時Brown給出了這樣的說法：
如果你正在構建的單體應用系統已成了一個大雜燴，或許你應該思考一下，你是否對軟件架構給予了足夠的關注？你是否真正地理解了什么是軟件中的核心結構抽象？軟件的接口和職責是否清晰？如果你沒有做到這些，那么為什么認為如果能遷移到微服務架構就會有所裨益？當然，對服務做物理分隔會強制性地規避一些捷徑。但是在單體應用中，也可以實現同樣的組件間分隔。
Hughson將使用微服務做構建比作為冰山，一眼看上去所顯現出來的部分，要遠小于位于水下的部分：
如果一個開發團隊不能或是不愿意去遵循設計的指導原則（例如，模塊化需求），這時額外地添加復雜性可能并非是所需的解決方案。將應用分布化，會使應用更不易于“意外地”糾纏于各種關注中，但并不會杜絕該問題的發生。
Gene借助于Brown的另一篇推文對最后一點做了說明：
Hughson進而返回到對開發團隊不能或是不愿意遵循設計指導原則的評論上，他繼續指出：
我的觀點是，增加“意外地”破壞模塊化的困難度并不會解決前面提及的兩組人員所面對的問題，即不能遵循設計指導原則的開發團隊，以及不愿意遵循設計指導原則的開發團隊。這頗具諷刺意味，那些并沒有理解模塊化必要性的人，可能無論各種障礙都會在他們的“解決方案”中頗具創造性。同理，對那些不愿意采用模塊化的人同樣適用。
Hughson提出，分布式（微服務天生就是分布式的）作為一種實現模塊化的手段，并不適用于目標。他認為，關注不應局限于應用架構上，也應同樣地適用于應用數據。
一個具有紀律的單體應用團隊，可以在單體應用數據架構中維護模塊化。而試圖共享一個單體應用數據架構的多個獨立團隊，可能會遇到嚴重的治理開銷問題，也可能會完全地破壞模塊化。
Christian Posta在去年就指出了為什么應用中的數據管理會成為遷移到微服務時的最難部分。InfoQ當時就對此進行了報道：
要對一個相當復雜的企業領域構建微服務，我們需要找到該領域中不同職責間的界限。在每個界限上創建一個針對該職責設計的、并表示了該職責的領域模型。進而，每個界限的數據模型被同一界限的領域模型所驅動。使用DDD就可以發現這些界限，并對每個界限創建一個“受限場景”（bounded context），這樣每個場景可轉變為一個微服務。
該文章的一條評論指出，這可能會需要一定形式的治理。對此，Hughson持贊同態度：
消極措施不足以解決問題，無論是結構性的（“讓我們將組件分布化，以免人們破壞模塊性”）還是過程性的（例如，“要有紀律”）。治理在應用層（在我看來，即應用架構原則）及以上層是完全有必要的，它有助于實現對競爭利益的協調，并監督設計以免在黑暗的小巷中徘徊。請記住，這可能是由于誤解、缺乏經驗、不符合規范甚至設計不一致而導致的。需要有人監控所發生的情況，以及同樣重要的發生原因。
總而言之，在Hughson看來，構建需要獨立管理、擴展和部署組件的應用時，微服務的確可以發揮自身的作用。理解到這一點是很重要的。但是，也需要很好地理解為什么要選取沿微服務這條路走下去。
查看英文原文： Microservices and Modularity
京公網安備 11010502049343號