DRY原則與微服務的矛盾：共享複用會導致耦合 - AllenHolub
DRY（不重複自己）原則不是法律，而是經驗法則。例如，在微服務中，最重要的是能夠更改單個服務並孤立地重新部署該單個服務。
如果使用共享庫迫使您重新編譯/重新部署多個服務，即使當前服務未使用剛更改的庫的一角，則您違反了?Service微服務原則。
因此，在微服務世界中，我們要麼不使用共享庫，要麼使它們非常細粒度，達到單個（無伺服器/ lambda）函式的水平。
同樣，通過增加複雜性以換得“靈活性”或“重用”是合理的。我們在許多層面上的最大敵人是不必要的複雜性。
眾說紛紜：
DRY的另外一面是耦合！
我看到的軟體越多，發現不適當的耦合是更多的錯誤來源。
耦合是當今軟體領域唯一的設計問題
服務依賴惹的禍：亞馬遜雲端計算又雙叒叕當機了，一半網際網路中斷 -The Verge
banq注：DRY是不要重複，實際目的是為了追求複用，但是如果純粹為了複用而複用肯定導致耦合，如果中臺概念是為了複用，肯定導致耦合，複用/可重用性第一的思維已經落後。
相關文章
- 重用或複用會導致耦合，微服務是寧可重複也不耦合 - Victor Rentea微服務
- 微服務劃分原則微服務
- 矛盾與規則的結算
- DRY原則的一個簡單實踐
- 軟體設計原則—合成複用原則
- DRY原則：識別模式並抽象概括 - javierdearcos模式抽象
- 耦合與聚合的區別比單體與微服務區別更重要微服務
- 設計微服務架構前應該瞭解的 5 項指導原則微服務架構
- 如何避免微服務設計中的耦合問題微服務
- 架構師進階，微服務設計與治理的16條常用原則架構微服務
- 微服務精華問答：什麼是微服務架構中的DRY？| 技術頭條微服務架構
- 淺複製導致的bug
- 會計財務系統的工程原則
- Spring使用實現類注入為什麼會導致高耦合度（舉例）Spring
- 一起玩轉微服務（8）——服務拆分原則微服務
- 【虹科乾貨】設計微服務架構的原則微服務架構
- 微服務中的資料共享微服務
- 交流耦合與直流耦合
- 引導分析原則
- 微服務導航微服務
- 真正需要學習的12個微服務設計原則微服務
- 物件導向設計的六大原則（SOLID原則）-——里氏替換原則物件Solid
- 設計習慣比較：高凝聚/松耦合、DRY/錯誤抽象 - Jesse抽象
- 軟體複用導致的軟體依賴問題 - research!rsc
- 開閉原則——物件導向程式設計原則物件程式設計
- 微服務之間如何共享DTO?微服務
- 物件導向OO原則物件
- [Spring Cloud Tutorial翻譯系列]微服務-定義、原則、好處SpringCloud微服務
- 【架構設計】保持簡單輕量設計的三個原則——DRY，KISS, YAGNI架構
- 幽默：服務架構的兩難與矛盾之處架構
- 微服務的Zuul萬用字元規則微服務Zuul字元
- 必知必會的設計原則——介面隔離原則
- 設計和架構：業務開發指導原則架構
- 不止於物件導向的SOLID原則物件Solid
- 物件導向的基本設計原則物件
- 物件導向的7大原則與23種設計模式物件設計模式
- 物件導向設計原則物件
- MySQL 網路導致的複製報錯案例MySql