架構中的耦合。首先需要看到，耦合是複雜系統必然的屬性之一，就像生物的細胞一樣，必須相互交換信息才能體現出正常的功能。但不合理的耦合卻是要極力避免的。我們常說高內聚低耦合。內聚是通過業務語義的關聯來組織的，那麼內聚帶來的，往往是模塊化（物理形式往往是DLL或者服務）。文中提到了具有高度功能內聚並可獨立部署的組件可使用架構量子來隱喻。這裏需要注意的是，如果想能夠真正獨立部署，往往離不開數據庫，框架或者其他第三方組件，而在架構設計時，顯然這種是最需要延遲決策的部分。因此，架構量子更多是從結構性元素的完整性來考慮，和一般常常提及的洋蔥架構、六邊形架構等還是在不同維度來討論架構的問題。此書提到架構師面對的是架構量子。顯而易見，架構量子越小，其可複用能力和可組合能力越強，因此架構師需要根據限界上下文劃分合理的邊界。
架構模式顯著影響架構量子的大小，但不是決定架構量子大小的唯一因素。常見的模式包括：大泥團，單體（非結構化，分層，模塊化，微內核or插件化），事件驅動（代理-無狀態，中介-消息總線），服務導向架構SOA（基於ESD的SOA，微服務，基於服務的架構）。
微內核主要基於API（契約），通過語義耦合來對接各個插件，同時還需要有膠水代碼來黏合內核和插件。
事件驅動架構從原理上來講，是去耦合最好的方式之一，各個消息消費者的可測試性也比較好。但代理的問題是，流程化難以測試。而中介架構的問題在於，協調者複雜度異常高。
基於ESD的SOA中，消息總線主要用於進行任務編排，中介路由，消息轉換等。它和傳統的分層架構有些類似的地方。總體而言，基於ESD的SOA不利於演進，其架構量子粒度相當大。
微服務則將每個業務流程整合成一個服務，每個服務即爲一個架構量子。但這裏有個小疑問：對於一些公用服務，比如數據庫服務，是作爲一個微服務存在嗎？那其他的需要和數據庫服務打交道的服務，其必然依賴於數據庫服務，架構量子邊界如何確定？
微服務架構通常遵循7大原則：
- 微服務重點是基於業務領域而非技術領域。其粒度並不是越小越好。架構量子的確定是依據業務上下文和流程。
- 隱藏實現細節。細節藏於服務內部。服務之間通過消息/資源傳遞來集成。
- 自動化文化
- 高度去中心化。即無共享模式。既然是武功鄉，那麼就會只能通過允許一定的概念冗餘來消除耦合。比如某個概念假設有50個屬性，可能每個服務只使用其中的10個，那麼這個概念就存在於多個服務中，服務之間通過消息/資源將此概念的部分屬性傳遞給其他服務。這樣的優勢在於，變更更加獨立。疑問：比如一件商品，在系統內會有唯一的一個編號，那這個編號難道不是共享信息嗎？如何解決編號的產生和消亡的呢？一個可能的方法，是有個商品管理的服務，通過它來管理並將此消息傳遞給其他服務。
- 獨立部署。服務獨立升級不影響其他服務。
- 隔離失敗。這裏需要學習一下部署流水線和DevOps最佳實踐。
- 高度可觀察。只能藉助於監控和日誌。那麼這些基本能力顯然是在各個服務中都需要使用的，那麼必然還存在一些技術耦合點。通過服務模板的配置化來解決？參考Drop Wizard和Spring Boot。
疑問：服務是如何集成的？有無服務註冊？業務流程如何在服務間流動的？
微服務vs基於服務的架構，三個主要區別：
- 粒度。基於服務的架構粒度更大
- 數據庫作用域。基於服務的架構往往事務性更強，這種場景不適合使用微服務架構。
- 服務中間件。基於服務的架構，需要藉助於服務總線進行Bridge和Coordinate。
架構模式最終是爲現實問題服務的，因此必須首先弄清楚現實問題域，然後纔是選擇合適的架構去匹配和解決問題。