在領域驅動下使用 Clean Achitecture 實現高可用軟體架構
圖（一）、Bounded Context 前言 先前筆者撰寫許多關於軟體架構相關文章，有敏捷的軟體架構、也談過 Clean Architecture、包括我自行設計的跨平台的 Web API Framework 框架 Easy Architect Framework 等等，不管談論哪一種都圍繞在軟體本身的高可維護性、擴充性等議題，但常言道，能力（技術）要在更往上一步就得忘掉現在所有所學的東西，不要被現有學習的東西所牽絆才能更上一層樓，金庸裡的張無忌也是忘掉九陽神功與乾坤大挪移後也才瞬間學會的張三丰的太極拳法，因為長久以來你都使用瀑布開發方法，專案也都能成功結案，看似當然也無問題，因為剛好都在你熟悉的產業即便設計完才做開發也不致有你非預期情況會發生，因為你已經非常熟悉改產業、但當遇到其他產業時，專案實作過程中便會遇到需求認知錯誤、錯估範圍、部分打掉重練、時間浪費、人力不足、現有架構無法發揮功用、時間到最後便不足而最後導致專案失敗的窘境，這就是熟悉一種開發方法時，久了就會無視其他的開發方法，就像 OOAD 非常熟悉，解決各種軟體開發大小問題都會迎刃而解，系統開發 90% 都可以在經驗種解決，最後也會無視訪間流行的它種開發方法像是 DDD 等等，但是當你遇到 cloud 環境、Microservices、或者 Serverless 環境的時候，你不再是以單就以物件的角度來思考、在分散式環境裡，有些是違背物件導向思考方式的，你可能是使用流程角度來思考，領域驅動開發的概念也應蘊而生。 DDD, Domain Driven Devlopment 領域驅動開發 近幾年來、DDD 領域驅動概念不斷的蓬勃發展起來，這是因為 Cloud/Microservices 議題不斷的是重視，傳統的 SOA 已經慢慢不敷使用了，如果要應付更大量的服務需求吞吐量、不太可能像傳統架設單一伺服器來解決，在領域驅動裡使用 Bounded Context 的概念來分界模型 Domain Modeling 的應用範圍，讓團隊成員在進行合作時什麼該保持一致？Bounded Context 與其他的 Bounded Context 該如何構通？以及『上下文如何關聯』有一個明確且共通的術語 Ubiquitous Language，這共通的語言可以是某一段程式碼、或者是團隊的組織、軟體系統機的介接用法、或者