可落地的DDD(5)-戰術設計

時間 2019-11-17

原文原文鏈接

摘要

本篇是DDD的戰術篇，也就是關於領域事件、領域對象、聚合根、實體、值對象的討論。也是DDD系列的完結篇。這一部分在咱們團隊爭論最多的，也有不少月經貼，好比對資源庫的操做應該放在領域服務仍是領域對象中。聚合根應不該該暴露給外部，仍是要轉成DTO。這些問題咱們討論了大半年，最後你們基本達成了共識，在當前的業務規模下，這些問題沒那麼重要，可東可西。不會對代碼的質量有啥大的影響。關於DDD的實踐，與團隊的水平、業務複雜度息息相關。咱們的經驗並不必定就適用大家團隊。我將戰術篇的這麼多的內容放在了一篇文章中，而且大部分都是引用以前的討論、總結。緣由仍是在於我心裏深處並無以爲戰術篇的實踐給咱們團隊帶來多麼大的改變。戰略篇的是我認爲更重要的。html

DDD系列文章斷斷續續也有十來篇了，主要是總結咱們團隊落地過程遇到的問題和解決方案，算是DDD從學習到落地實踐的一個完整的閉環鏈路，但願對你有所啓發。固然這個過程受益最大的確定是我本人。系統性的思考問題、總結問題、闡述問題是很是有助於提高我的思惟能力，朋友們大家也能夠嘗試一下。git

建模

DDD的出現，是你們對於事務性編程，面向數據庫表編程的一個反思，明明軟件設計是一個面向對象的設計，須要考慮對象之間的繼承、多態、組合。爲何到實際編碼過程當中成了過程性的編程，爲何對象只有屬性沒有方法了，也就是失血模型。github

關於這幾種編程的詳細介紹能夠參考Martin的《Patterns of Enterprise Application Architecture》Page110數據庫

因此我我的以爲，DDD的做用有兩個，一個是面向業務的，幫助分析業務模型，進行業務建模。另一個是面向解決域，即代碼落地。即便用一個規範可以反映對象之間的關係，即OO編程。編程

目前對DDD研究主要有如下類別設計模式

關於業務分析層面，如何進行概念層面的抽象和設計的方法論
關於服務劃分、代碼分層、職責定義的方法論
DDD框架的討論，好比jdon

第3點基本上沒怎麼普遍的討論。我認爲將來也不會出現什麼牛逼的DDD框架可以流行起來。DDD是一種建模方法，是針對不一樣的業務領域的，在不一樣的團隊有不一樣的落地方案，是沒辦法靠一種框架來約束，來把一件不統一的事情來統一塊兒來。就比如咱們面向對象的設計針對問題域，抽象出來了 20多種設計模式。這些設計模式都是指導思想，你不能搞出一種框架，來約束你們使用某種設計模式就基於這種框架擴展，以此來達到代碼統一或者下降編程難度的目的。緩存

前面的文章主要是比較大的方面，比較適合作總體業務分析。也就是第一個點。今天主要討論第二點。架構

OO 編程

DDD的代碼分層、職責定義本質上就是OO編程。OO的三大基本要素就是繼承、多態、組合。這三個是深度抽象的結果。無法指導具體的編程。因而咱們有了設計模式，前輩們針對問題域，總結除了24種設計模式，這樣遇到相似的問題時，咱們可使用對應的設計模式去解決問題。而這些設計模式底層使用到仍是繼承、多態、組合。app

那有了設計模式了，爲何還要DDD呢？爲何不多看到開源軟件用DDD呢？我的的理解DDD仍是面向企業應用架構的，是在衆多不肯定的業務，系統中提煉出來的一套規範，這樣必然是高度抽象的。而開源軟件大可能是領域比較肯定的，好比數據庫領域，中間件領域。解決這類問題的系統架構一般會更加複雜以及具備擴展性。框架

DDD的工程架構網上有不少，我在以前的文章也提到過，這裏再也不贅述，看下老馬的這個，我以爲很是清晰的展示出來了職責分離 martinfowler.com/articles/mi…