適應度函數，本質上就是一組評估函數，用以評估架構在不同維度上的表現，並從全局角度進行平衡，從而實現增量和引導式演進。簡言之，其實就是能夠構建出一套架構監控機制。
適應度函數，並不一定全部採用自動化手段，甚至某些維度不可能採用自動化手段。評估函數的確定，和問題域密切相關。需要識別出關鍵維度和相關維度。
架構特性---適應度函數----探索式架構設計
工程效率提升（CI）----這裏聯想到百度的工程效率部。
微服務架構，讓我聯想到Erlang的進程，所有進程都是獨立的，相互不耦合，僅僅通過消息進行通訊。此處的進程並不是操作系統進程，而是虛擬進程。這讓版本升級異常簡單，甚至可以實現不中斷服務的熱升級。而微服務架構，只是這種思維的一種特別版本。服務是單獨的進程，運行於Docker容器中，服務本身也支持了橫向伸縮。需要徹底瞭解：微服務和WebService到底有何區別？
如何評估架構的長期有效性？一個架構，只有經過設計、實現、測試、升級和變更這個生命週期之後，才能得到有效評估。簡言之，只有真正在暴風雨中生存下來的，纔是具有長期演化可能的架構。
那麼如何評估呢？除了無法避免的手工評估手段之外，自動化評估工具集是更關鍵性的手段，而如果要做到自動化，則可測試性必須在架構設計時給予充分的考量和設計。也就是說，可測試性本質上是需要設計的。自動化評估最大的優勢是可以根據需要靈活調整其運行的時間、頻率，並可以重複執行。
假設驅動開發是個頗有創意的思路。它避免了依賴於單個BA或者市場人員對需求的把握，而是通過技術手段，採用不同策略並行的方式，繼而通過統計來從用戶行爲中學習，從而構建出更有價值的系統。本質上假設驅動開發仍然屬於反饋環，用戶亦作爲反饋環的重要環節參與其中。假設驅動開發可以使用的技術手段很多，比如微服務中，可以通過服務路由來確定哪些服務最被常用；比如傳統軟件中，通過增加用戶操作日誌來採集用戶行爲並對其進行分析。