DDD（Domain-Driven Design 領域驅動設計）是由Eric Evans最先提出,目前也有十多年的歷史了，一直處于不慍不火的狀態，短短幾年云計算，大數據和AI各種框架，概念推出就得到各大科技公司的大力支持，隨著互聯網業務的規模越來越大，為了快速響應需求，微服務快速崛起解決了一些問題。但漸漸我們發現，技術的快速發展只是解決了一部分問題，業務的復雜性帶來的架構挑戰單純從技術層面是解決不了的。

微服務從業務角度上看，實質是對業務領域進行了劃分，加上DevOps，以對業務快速響應。微服務的成功也使我們思考業務建模的重要性。以前架構師拿到需求時，很多時候都是通過經驗（by experience）來進行業務建模，映射到數據模型上，得到實體關系后再映射到類圖上，業務活動抽象成一個個時序邏輯，從而翻譯成代碼。是的，在信息化不高，需求變化不快的企業應用里面，是一條可行的道路。

互聯網的滲透到社會生活的各個領域后，我們漸漸發現，這套路走不順了，如果業務建表不當，可能帶來的是架構為了適應業務不斷地妥協和腐化，從而帶來巨大的維護成本。這里，需要從業務的憑經驗設計，尋找更好的設計思想來解決越來越復雜業務問題。DDD也漸漸又重新回到人們的視線里面。

我曾經歷一家初創的公司，它的信息化系統是通過VB+SQLServer的一堆存儲過程實現的。各種物流流程就是業務表和SQL。我進去時，正當它轉型使用流行的Java開始重構各類應用系統。使用流行的SSH，各類配置文件讓人頭大，能把環境搭建起來跑通就謝天謝地了。同樣，數據庫也是我們的中心，各種業務首先想到怎么建表，沒人會想什么DDD，也沒聽說過。后來，進入了互聯網，快速的業務迭代，漸漸開始做業務設計，架構設計。無意中接觸了DDD的概念，感覺像很難理解。什么限界上下文，聚合根等，與傳統的軟件語言格格不入，我判斷它看起來很美，卻基本無法落地。要讓團隊成員理解這些概念，很難。后來就沒深入了解了。

隨著微服務技術體系的成熟，從容器化到k8s,從DevOps到NoOps，從serverful到serverless,云計算領域越來越細化，但為什么還會面臨軟件維護成本并沒有和技術進步帶來的好處成反比呢。當重新思考這個問題時，回顧過去參加過的各類體系統開發設計，會發現很多時候注重了技術架構但忽略了它真正服務的對象，業務。真正好的架構應該是適應業務發展的。那業務應該怎么通過建模，映射到技術架構上呢。DDD是一套完整的業務建模理論，我漸漸開始關注DDD的發展。

總結一下，我們面臨的問題是，業務規模的增長帶來結構變化的復雜度增大，我們需要快速響應業務變化的能力，而DDD提供業務領域設計建模型的一套方法，從憑經驗設計(by experience)到理論引導，一套穩定的從業務至代碼模型的解決方案。