至此，本書提供了一套主觀的做法，以六角架構風格打造 Web 應用——從組織程式碼到走捷徑，回答了這種風格帶給我們的諸多問題。

• 書中有些答案也適用於傳統分層架構。
• 有些答案只能在本書這種以領域為中心的方法中實作。
• 還有些答案你或許並不認同，因為在你的經驗中行不通。

但我們最終想回答的問題是：究竟何時該用六角架構風格？何時又該堅守傳統分層風格（或任何其他風格）？

從簡單開始#

一個讓作者花了太久才領悟的重點是：軟體架構不是專案開頭定好、之後就會自己照顧自己的東西。 我們不可能在專案之初就掌握設計優秀架構所需的一切資訊！架構可以、也應該隨時間演進以適應變動的需求。

這意味著我們無法得知長遠來看哪種架構風格最好，未來甚至可能需要更換架構風格！要讓這成為可能，就得確保軟體易於變更——也就是埋下那顆可維護性的種子：

• 可維護性意味著要讓程式碼模組化，好讓我們能孤立地處理每個模組、必要時在程式庫中移動它。
• 架構需讓模組間的邊界盡量清晰，避免不想要的依賴意外滲入而降低可維護性。

專案之初可能只是一堆 CRUD 使用案例，這時以領域為中心的六角架構或許殺雞用牛刀，不如選更簡單的「以元件為基礎的方法」。或者你對專案已了解夠多、一開始就要建構充血領域模型，那六角架構風格可能就是正確的起點。

演進領域#

隨時間推移，我們對軟體需求了解越來越多，也就能對「最佳架構風格」做出越來越好的決定。應用可能從一堆簡單 CRUD 使用案例，演進成擁有大量業務規則、以領域為中心的豐富應用——此時六角架構就成為好選擇。

前幾章應已清楚呈現：六角架構風格的主要特徵，是讓我們能在不受持久化關切與外部系統依賴等干擾的情況下開發領域程式碼。作者認為「讓領域程式碼免於外部影響地演進」是支持六角架構風格最重要的單一論點。

這也是它與 DDD 實務如此契合的原因。DDD 中由領域驅動開發，而當我們不必同時思考持久化等技術面向時，最能清晰地推理領域。作者甚至會說：六角這類以領域為中心的架構風格是 DDD 的促成者——沒有一個把領域置於中心、並把依賴反轉朝向領域程式碼的架構，就不可能真正落實 DDD，設計總會被其他因素牽著走。

因此，判斷是否該用本書架構風格的第一個指標是：若領域程式碼不是你應用中最重要的東西，那你大概不需要這種架構風格。

相信你的經驗#

人是習慣的動物。習慣替我們把決策自動化，省去思考的時間——獅子衝過來就跑；要建新 Web 應用就用分層架構，因為過去做太多次、已成習慣。

作者並非說習慣性的決定必然是壞決定——習慣既能助我們做出好決定，也同樣能助我們做出壞決定。重點是：我們往往只做自己熟悉的事，對過去做過的感到自在，於是何必改變？

因此，要對架構風格做出明智決定的唯一途徑，就是累積對不同架構風格的經驗。若你對六角架構風格沒把握，就在當前正在打造的應用中挑一個小模組試試：熟悉概念、建立自在感、套用書中想法、加以修改、再加入自己的點子，發展出一套讓你自在的風格。這份經驗，將能指引你下一次的架構決策。

看情況#

作者多希望能提供一份像社群網站上「你是哪種人格類型？」「如果你是一隻狗會是什麼狗？」那樣的選擇題清單，來幫你決定架構風格。

但事情沒這麼簡單。作者對「該選哪種架構風格」的回答，始終是專業顧問的那句——「看情況（It depends）」：取決於要打造的軟體類型、取決於領域程式碼的角色、取決於團隊的經驗，最終，也取決於你對某個決定是否感到自在。

無論如何，作者希望本書已激起一些靈感的火花，幫助你面對架構這道難題。若你有關於架構決策的故事——無論是否與六角架構有關——他都很樂意聽聽。