圖來自網絡

軟件架構的終極目標：最大化程序員的生產力，最小化運營的總成本。

前奏

目前我在看兩本書《領域驅動設計精粹》和《實現領域驅動設計》，前一本比較薄，不到150頁，後一本就非常厚實了，有500多頁，那麼讀起來可能就會顯得有點心理障礙，但如果要想更多瞭解DDD，還是要以第二本爲主，第一本可以作爲概要性閱讀。

領域驅動設計，類似**驅動，我們也接觸過不少，比如測試驅動，敏捷驅動等等。領域驅動設計，這六個字或者在前面再加上業務兩字，業務領域驅動設計，最終的目標都是爲了設計服務的，那麼設計是設計的什麼，肯定是應用程序系統架構，那麼應用程序系統的架構有什麼樣的需求呢。

架構有兩種需求：功能性需求和非功能性需求 。

功能性需求就是我們在使用一個系統的時候所接觸到的，所用到的諸多功能，比如發佈一個商品，展示一個統計報表，做權限的管理和控制等，代表的是一個應用程序系統架構能做什麼。

非功能性需求是我們的這個應用程序系統架構是否做到了可監控、可擴展、是否高可用、高性能等，代表的是一個應用程序在運行時的質量。非功能性需求中，還有一個非常重要的點就是：快速安全的交付軟件。

那麼我們就隨着如何快速安全的交付軟件說起。 DDD重要的指導思想之一是將業務人員和研發人員拉在了一起。 敏捷開發的週期內，無論需求梳理會、回顧會還是計劃會都沒有業務人員的影子，總是研發和產品在交流。

在業務建模之後技術人員來考慮如何快速且安全的交付軟件產品 。

隨着軟件架構的逐漸成熟，在我們已經認識的AKF立方體中，在X軸的服務器水平復制，和Z軸的數據分庫分表，這兩個方向上我們的技術都已經相對成熟，使得我們在抗住大訪問量方面已經不再被動。

但唯獨在Y軸這個方向上，業務對應服務的拆分，和應用程序被要求快速的交付，我們始終沒有太好的解決方法。

而DDD正是致力於在這個方向上爲軟件開發人員做指導的 ，利用DDD如何快速的交付軟件。

因爲這是我的DDD學習筆記第一篇文章，就花費了上面的篇幅來做個淺顯的對DDD的理解引入描述。接下來我主要談一談DDD學習中的戰術設計中的一種：運用領域事件進行戰術設計。

事件產生於核心域

領域驅動設計中涵蓋的內容基本是兩大內容，戰略設計和戰術設計，領域事件是屬於戰術設計的範疇內的。

那麼是先有的事件還是現有的領域呢，我個人認爲在動作發生關係上，是先有的事件，已經存在發生過去一段時間了。

比如我們在利用事件驅動開發的時候，常常藉助的中間件就有很多，ActiveMQ、RocketMQ等等。後來我們有了領域的概念認知，那麼就開始使用領域的思維來去思考事件：領域事件。

如今藉助了領域的概念，我們相當於換了一種思考方式，好比 “橫看成嶺側成峯，遠近高低各不同”，最終都是山，但 “成峯” 的時候可能更能便於我們理解和認知我們的業務關係，我們就使用 “成峯” 的角度去思考。

假如在一個月前我還沒有接觸領域事件，上面也說了我們一直在用消息機制（消息中間件）解決問題。那麼現在我開始學了領域事件給我帶來什麼變化或者新的認知呢。

首先，我覺得是統一了語言：領域事件，好比古人一手取了一根木棍，另一隻手又取了一根木棍，兩隻木棍來回摩擦，生出火來。這件事情很偉大，但描述起來就比較費勁， 後面就有人總結說了叫做：鑽木取火 ，這樣傳播起來就方便了，大家一聽到鑽木取火就知道是什麼意思。

領域事件也是如此，因爲之前畢竟你已經有了領域上下文的知識。

總結

沒有DDD，我們業務中也是已經存在了邊界，關係，交互，有了DDD之後，我們是依靠或者藉助其幫我們梳理這些業務關係，劃清業務邊界，形成獨立性、自治性、弱耦合的系統。

當我們閱讀相關DDD書籍裏面描述的對象和實踐時候使用的對象，都沒有變，那些對象都是一直存在的。但是，我個人認爲DDD是一種思考業務問題、架構問題的方式， 學習了DDD知識以後就可以採用“DDD的思維方式”去理解和處理那些我們在工作中已經存在的對象。

但也要明白，它絕不是解決一切問題的銀彈。

DDD就是一種工具，好比是一把劍，也可能有另外一種工具XXD，好比是一把刀，至於是劍厲害，還是刀厲害，主要看你使用的熟練程度。

參考書籍 《領域驅動設計精粹》和《實現領域驅動設計》 和《架構整潔之道》