- 演進式架構的陷阱和反模式
- 反模式：供應商爲王。即以供應商提供的架構爲核心來組織自身業務，被供應商掌控全局。類似於20200517的HW事件，美國通過掐斷半導體晶圓片的供給（非禁止，要許可）。也就是說，如果你的商業帝國強烈依賴於第三方供應商（尤其是不可替代），那麼可能大廈一夜即傾。
- 陷阱：抽象泄露。所以重要的抽象，在某種程度上都會泄露。隨着技術棧的不斷變化，如何保證業務在技術不斷髮展時還能保持一定的穩定性？當然，重建幾乎是不可避免的，但如果能在重建時付出的代價較小，顯然對組織的研發效率是具備正面效應的。
- 反模式：最後10%的陷阱。世界是複雜的，需要用動態平衡的思維去解決問題。如果企圖使用某種快速開發工具來構建大型複雜軟件，最終10%的需求大概率會無法滿足，這時再回歸通用語言就會代價奇高。
- 反模式：代碼複用和濫用。複用代碼更像是器官移植而非樂高積木。樂高積木是軟件設計的高級階段，是理想。複用在某種程度上，確實是種耦合。在微服務架構中，通過增加重複來儘量減少耦合（耦合無法避免）。但更佳的思路，應該是允許對代碼複用（在一定程度，應該提倡複用），但代碼複用後，要允許業務開發者針對此代碼進行擴充或者修改。一種更理想的方式是，對可複用代碼也設置適應度函數，保證其在不斷有新需求的情況下，仍具備演進能力。否則，複用代碼會很快腐爛，因爲需求的變化是必然的。在這裏，還要撇清一個可能誤導的概念。微服務強調的重複，應該是在服務間的。如果在服務內部，一個概念應該還是要有唯一的表達。
- 陷阱：簡歷驅動開發。不要爲了架構而構建架構，構建架構是爲了解決問題。
- 反模式：管理不當。警惕（但不應該杜絕）一切共享型的導向。要始終從問題域入手，實事求是。金髮姑娘與三個小熊，隱喻了可以針對不同的項目特點，來選取不同的架構模式。
- 陷阱：發佈太慢。演進的速度和生產週期成正比，生產週期越短，演進速度越快。生產週期是指從真正寫代碼開始到系統發佈？
- 陷阱：產品定製。定製必然導致不同的版本分支，增加開發管理和測試的負擔，同時影響演進速度。需要對定製需求做一個實事求是的評估，而不是爲了銷售無限制定製化。
- 反模式：報表。報表，爲了性能和接口設計考慮，一般會直接和數據打交道，因爲一張報表往往涉及到大量的數據，顯然使用一堆數據進行接口傳遞是不現實的。但其他典型應用則不同，往往一個操作僅涉及少量的數據，這種一般都會通過DAS這種層次進行分層設計。
- 陷阱：規劃視野。企圖通過前期（編碼之前）大量投入來分析最初需求並制定嚴格規劃來保證軟件長期成功的做法，最終被證明是失敗的。面對需求越來越易變的趨勢，只有敏捷才能保存彈性。還是那句話，要從動態平衡的觀點來看待系統演進。注意沉沒成本，路徑依賴。