《領域驅動設計之PHP實現》全書翻譯 - DDD入門

時間 2020-01-15

原文原文鏈接

DDD 入門

若是你已經讀過 Vaughn Vernon 和 Eric Evans 著做裏的這些主題，你可能會很熟悉咱們講的是什麼，由於咱們大量借鑑了他們的定義和解釋。領域驅動設計（DDD）是一種幫助咱們理解和構建軟件模型設計的方法。它提供了戰略和戰術模型工具來幫助咱們設計高質量的軟件從而達到咱們的業務目標。前端

本書的主要目標是向你展現領域驅動設計戰略模式的 PHP 代碼實例。若是你想了解更多戰略模式和領域驅動設計的核心，你最好去讀 Vaughn Vernon 的《領域驅動設計精簡版》和 Eric Evans 的《領域驅動設計參考：定義和模式摘要》。

更重要的是，領域驅動設計不是關於技術的。相反的，它是關於圍繞業務挖掘知識，用技術來提供商業價值的。只有當你有能力理解你公司的業務時，你纔可能參與到軟件模型的探索過程，從而獲得一個通用語言（Ubiquitous Language）。程序員

爲何領域驅動設計重要

軟件不只僅是代碼。若是你好好思考過這一點，代碼絕非咱們所追求的最終目標。代碼只不過是解決業務問題的手段。領域驅動設計強調要確保業務和軟件使用同一語言。因此爲何非要用不一樣的語言來說述呢？只要打破其中壁壘，就再也不須要翻譯或者繁瑣的同步過程，信息也不會丟失。每一個人均可覺得探索業務領域作出貢獻，而不只僅是程序員。最終所產出的軟件就是公共語言的真實體現。web

領域驅動設計同時提供了戰略和戰術設計的框架 -- 戰略設計精肯定位業務中最重要的領域，根據業務價值來進行開發；戰術設計則經過久經考驗構建塊和模式來創建可工做的領域模型。數據庫

領域驅動設計的三個核心

領域驅動設計是交付軟件的一種方法，它主要彙集三個核心要點：segmentfault

1. 通用語言

爲了創建業務領域的共同語言，領域專家和軟件開發人員須要一塊兒工做。這裏沒有咱們與他們之分，這裏只有咱們。開發軟件是一種商業投資而不只是花銷。爲構建通用語言而做出的努力將幫助團隊全部成員對領域有更深的認識。緩存

2. 戰略設計

領域驅動設計指明業務方向背後的戰略，而不只僅是技術層面。這有助於定義內部關係和早期預警反饋系統。在技術面，戰略設計經過提供如何實現面向服務架構的動機來保護每一個業務服務。架構

3. 戰術設計

領域驅動設計提供工具和構建塊來持續交付軟件。戰術設計工具產出的軟件，不只是正確，並且同時是易測試的和出錯少的。框架

通用語言

通用語言，以及第十二章整合限界上下文，是領域驅動設計最具威力的一部分。異步

就上下文而言
如今設想一個限界上下文就是一個系統內的概念邊界，邊界內的通用語言是有其特殊含義的，而邊界外的上下文概念可能有不一樣的含義。

那麼，如何尋找，發現和捕獲這些很是特別的語言呢，下面將列出幾個要點：分佈式

識別業務流程的關鍵點，輸入和輸出
建立一些詞彙和定義
用一些文檔來捕獲重要的軟件概念
與團隊其餘人分享和擴展以上知識（開發人員和領域專家）

自從領域驅動設計誕生以來，改進構建通用語言進程的新技術層出不窮。其中最重要的也是現今使用最廣泛的，就是事件風暴。

事件風暴

Alberto Brandolini 在一個博客帖子上介紹了事件風暴及其好處，他解釋得比咱們簡潔多了。事件風暴，就是一種快速發現複雜業務領域的研討會形式：

它很是強大：它讓本身和許多參與者在數小時內提出一個完整業務流的綜合模型，而之前每每須要數週。
它很是吸引人：它整個想法就是爲了構建一個模型而把有疑問的人和知道答案的人聚在同一個屋子裏。
它很是高效：它所獲得的模型徹底切合領域驅動設計的實施方式（尤爲適合一種事件源方法），並能夠快速肯定上下文和聚合邊界。
它很簡單：它的表示符號很是簡單，也沒有複雜的 UML 以至參會者想從討論核心中抽身離開。
它頗有樂趣：我老是能主持一個美妙的工做會議，你們老是很投入並能提出超出他們預期的東西。正確的問題浮現了，氣氛也是融洽的。

若是你想對事件風暴瞭解更多，請查閱 Brandolini 的書 《Introducing EventStorming》。

關於領域驅動設計

領域驅動設計並非銀彈，就像軟件裏的一切都依賴於上下文。做爲一個經驗法則，使用它可讓你的領域模型簡單化，毫不會增長複雜性。

若是你的應用僅僅是以數據爲中心，用例也主要是在數據庫行列上作 CRUD 操做，即增刪改查，那麼你並不須要領域驅動設計。你所須要的僅僅是在數據庫之上作一個漂亮的前端。

若是你的應用少於 30 個用例，那最好使用像 Symfony 或者 Laravel 這樣的框架來簡單處理你的業務邏輯。

但是，若是你的應用超 30 個用例，你的系統可能走向一個可怕的大泥球。若是你知道你的系統肯定無疑會變得愈來愈複雜，那麼你應該考慮用領域驅動設計來應對這些複雜度。

若是你並不理解你工做中那些領域，由於它們很陌生，以前也沒有任何人給出解決方案，那麼對你來講應用領域驅動設計將變得很複雜。在這種狀況下，你最須要與領域專家緊密工做來獲得正確的模型。

棘手的部分

應用領域驅動設計並不容易。它須要時間和努力來投入到業務領域，術語，文獻中，而不是代碼堆裏。你須要領域專家承諾參與到整個進程當中。這須要一個開放的，友好的持續交流，來將他們的行話（spoken lauguage）轉化爲咱們的軟件模型。另外咱們要努力避免使用技術思惟，而應該首先認真思考對象的行爲和通用語言。

戰略總結

爲了給出領域驅動設計戰略這部分一個整體歸納，咱們將用 Jimmy Nilsson 的書《應用領域驅動設計與模式》中的一種方法，即考慮兩個空間：問題空間和解空間。

在問題空間裏，領域驅動設計用領域和子域來規劃和規類公司想要解決的問題。在在線旅行社（OTA）這個例子當中，問題是關於處理像航班機票，酒店預訂這樣的事情。這樣的領域就能夠規劃爲不一樣的子域，如價格，庫存，用戶管理等等。

在解空間裏，領域驅動設計提供兩種模式：限界上下文和上下文映射圖。其目標是定義如何爲全部已識別的子域提供一個實現，經過定義他們的交互和這些交互的細節。繼續用 OTA 這個例子，每一個子域問題都將用一個限界上下文實現來解決。例如，一個由價格管理子域團隊開發的自定義 web 應用，以及用戶管理子域的一個現成解決方案。上下文映射圖將展現每一個限界上下文是怎樣與其它部分發生關聯的。在上下文映射圖內，咱們能夠看到兩個限界上下文間有什麼關聯形式（例如：客戶-供應商，夥伴）。理想的方案是每一個子域由一個限界上下文實現，但實現不可能老是如此。就實現來講，依照領域驅動設計你就最終以一個分佈式架構結束。正如你已經知道的，分佈式架構遠比單體架構複雜，那麼爲何這個方法有意思，尤爲是對大而複雜的公司來講？這真的值得嗎？是的，它值得！

分佈式架構被證實能提升企業總體生產效率，由於它能爲你的產品定義好邊界，從而讓專門的團隊來開發。

若是你須要解決的領域問題不是很複雜，應用領域驅動設計的戰略部分會增長沒必要要的開銷同時會拖慢你的研發速度。

若是你想了解更多關於領域驅動設計的戰略部分，你應該去看看Vaughn Vernon的書《實現領域驅動設計》的前三章，或者Eric Evans的《領域驅動設計：軟件核心複雜性應對之道》，兩者對於這方面都有專門的講解。

相關趨勢：微服務與自包含系統

如今還有一些其餘遵循領域驅動設計的相關運動正蓬勃發展，微服務和自包含系統就是很好的例子。James Lewis 和 Martin Fowler 在 Microservices Resource Guide 裏是這樣定義微服務：

微服務架構風格是把單個應用的開發分解爲一個個小的服務的方法，每一個服務都有本身獨立的進程和輕量的通訊機制，一般是用 HTTP 資源的 API。這些服務都是圍繞其業務能力構建，可獨立部署自動升級，去中心管理。服務能夠用不一樣的程序語言編寫，使用不一樣的數據存儲技術。

若是你想了解更多關於微服務的內容，他們的指導就是一個良好的開端。微服務是怎樣與領域驅動設計發生關係的？按照 Sam Newman 《微服務設計》 一書中的解釋，微服務就是領域驅動設計的限界上下文的實現。

除了微服務，另一個相關的趨勢就是自包含系統（SCS)，依據自包含系統官網的解釋：

自包含系統是關注將功能分離至許多獨立系統的一種架構，由這些獨立系統相互協做來提供一個完整的邏輯系統。這能夠避免單體系統不斷成長致使最後變得不可維護的問題。縱觀過去的幾年裏，咱們看到許多中型和大型項目受益於此。這個思路是把一個大型系統分解爲一些更小的自包含系統，依照下列肯定的規則（官網上一樣有闡明自包含系統的七個特徵）：

每一個自包含系統是一個自治的web應用。對於自包含系統裏的全部處理數據的邏輯和全部渲染 web 界面的代碼都包含在其中。一個自包含系統能夠徹底自主處理其全部的用例，不用依賴其它可用的系統。
每一個自包含系統由一個團隊管理。這並非必然意味着只有一個團隊才能夠改變代碼，不過全部者團隊能夠最終決定什麼能夠放進代碼庫，例如合併，拉取請求。
不一樣自包含系統或者第三方系統間的通訊任何狀況下都應該是異步的。尤爲是其餘自包含系統或擴展系統不該該同步訪問自包含系統內的請求/回覆。這一點能幫助解耦系統，減小失敗結果，所以能支持自治性。其目的是關於時間上的解耦：一個自包含系統能夠很好的工做即便其它自包含系統臨時離線。即便通訊技術層次是同步的也能實現，例如複製數據或緩存請求。
一個自包含系統有可選的服務 API。由於每一個自包含系統都有本身的 web UI 同用戶交互，因此不須要一個 UI 服務。不過即使如此，爲移動客戶端或者其餘自包含系統而存在的 API 仍然是有用的。
每一個自包含系統必須包含數據與邏輯。要真正實現任何有意義的功能，二者都是必需的。一個自包含系統應該經過自身實現全部功能所以二者缺一不可。
一個自包含系統經過自身的UI將功能交給最終用戶使用。所以自包含系統不該該與其餘自包含系統共享UI。自包含系統可能仍舊與其它系統有關聯。不過，異步整合意味着即便在其餘自包含系統不可用的狀況下還應該能正常工做。爲避免緊耦合，一個自包含系統不該該與其餘自包含系統共享業務代碼。也許能夠經過建立一個自包含系統或者公共庫，例如：數據驅動層或者認證客戶端。

練習

與你的同事討論例如分佈式架構的利弊。考慮用不一樣語言，部署過程，責任心等等。

小結

在這一章裏你將學到：

領域驅動設計不是關於技術的；它的價值其實是經過聚焦你工做領域中的模型體現的。每一個人都參與到領域發現的過程，開發人員和領域專家用相同的語言來共同創建知識，即通用語言。
領域驅動設計提供戰術和戰略模型工具來設計高質量軟件。戰略設計關注業務方向，幫助明確內部關係，用明確的強邊界嚴格地保護好每一個業務服務。戰術則爲迭代設計提供有用的構建塊。
領域驅動設計只有在明確的上下文中才有意義。它並非軟件中全部問題的銀彈，因此是否用它應根據你手中工做的複雜度來決定。
領域驅動設計是一項長期投資；它須要長期努力。開發人員須要與領域專家緊密合做，同時要根據業務思考。最後，業務中的客戶因素也是須要你考慮的。

實現領域驅動設計須要努力。若是它很簡單，那每一個人均可以寫出高質量代碼了。準備好了，由於你立刻就要開始學習怎麼寫這些代碼了，在讀的過程當中，你將能夠完美地描述清晰你公司現有的業務。享受這段旅程吧！