如何淺析架構設計的DDD設計模式

如何淺析架構設計的DDD設計模式，很多新手對此不是很清楚，為了幫助大家解決這個難題，下面小編將為大家詳細講解，有這方面需求的人可以來學習下，希望你能有所收獲。

1.  問題的闡述

在項目中,我們一般都是分層,大家最熟悉的就是UI,BLL,DAL層,或者在加上一個Services服務層.一般的項目就這樣設計了.由于越來越多的公司,社區倡導領域驅動設計(DDD),于是,又有了項目的分層的方式,DDD設計中的一些概念也引入了: Presentation, Service, Domain, Repository. 而且一般來說,有下面的對應關系:

但是在開發的時候,一會兒在項目中建立一個Domain的類庫,一會兒又在項目建立DAL,***的情況就是:UI, Domain, DAL等等. 其實這倒是沒有什么,說到底只是一個名稱的問題,但是在只后面隱藏的問題就是:對DDD的不了解,很多的時候只是注重了”形”,而沒有領會到”神”.

在項目中不是建立了名稱為Presentation, Domain, Repository的類庫,這個項目就是DDD開發了,不是這樣的.本來在分層的時候采用UI,BLL,DAL,自己是很熟悉的,但是這樣一攪和, ***反而把概念搞復雜了.

而且,在項目中,是采用原來樸實的那種三層,還是采用DDD開發,是要經過思考的,不是那DDD的方法來套.也就是說,不要為了DDD而DDD.就像當初我們學習設計模式一樣,沒有必要在寫代碼的過程中為了設計模式而設計模式.

2.  設計方法

到底是采用DDD還是那種樸實的三層,主要取決與業務層的設計和系統的復雜度.

如果系統確實很復雜,業務邏輯相當的復雜,那么建議采用DDD,因為DDD的引入就是用解決復雜性的.因為采用DDD的方法來設計業務邏輯層,那么業務邏輯層就只是關注業務邏輯的處理,至于怎么存儲和獲取數據,絲毫不關心,所以基于這個原因,在DDD中就引入了Repository的概念,Repository就是來輔助業務邏輯層處理數據的.

雖然我一直在提”樸實的三層”,其實DDD和它之間沒有什么很明顯的劃分了,這里我之所以特意的把他們劃分出來,主要就是因為我們在項目開發中一般是三層(或者N層),這里提出主要是為便于后面講述一些問題.

下面就開始講述一些業務邏輯層設計方法,相信大家看完之后,很多的疑惑就迎刃而解了.

業務層的設計方法有三種:Transaction Script, Active Record和Domain Model.

看過Flower的<<企業架構模式>>一書的朋友應該對上面的三個詞語很熟悉,在書中,這些概念講的確實很精煉,可能因為精煉,所以理解起來就不是很容易.

在本篇文章中,就涉及到了這些知識,只有把這些點講清楚了,之前的問題就能解決.

如果熟悉這些概念的朋友,也不妨看看,大家可以交流!

首先來看看Transaction Script(之所以沒有翻譯為中文，因為翻譯后的中文意思很容易讓人產生誤導)

其實Transaction Script就是過程化的設計方式，最直觀表現就是一個個的方法，每個方法做一個業務的流程。我們來看下面一個例子。例子的背景就是在電子商務網站中訂單的處理流程。

public class OrderManager      {          public void PlaceOrder(OrderDTO order)          {              // Validate order based on business rules              // Check for stock availablity on items ordered              // Add the order to the database              // Set the order id on the OrderDTO object          }          public bool CancelOrder(Guid orderId)          {              // Retrieve order from database              // Determine if the order can be canceled              // if order can be canceled, set as canceled              // return true/false if order was canceled          }          public bool AddItemToOrder(Guid orderId, OrderItemDTO ItemToAdd)          {              // Retrieve order from database              // Determine if the item can be added to the order              // Add a new item row in the database              // return true/false if item was added to the order          }          public bool ProcessOrder(Guid orderId)          {              // Check to ensure this order can be processed.              // Validate order based on business rules              // Update the stock levels of products ordered              // return true/false if order was processed          }      }

在上面的代碼中，所有和訂單處理有關的邏輯都寫在OrderManager類中。類中的每一個方法就對應業務邏輯中的一個流程或者說對應一個use case，例如：CancelOrder就是取消訂單。

通過Transaction Script的方式來組織業務邏輯，一個很好的好處就是直觀，很容易理解代碼在做什么。如果有新的流程來了，再加一個方法就行了。

同時，這種組織方式的弊端就在于，當系統中的業務變得多而且復雜的時候，那么這樣的方法就開始變多，***的結果就是一個類中有成百上千個方法。而且這些方法中，除了一些基本的驗證可以提取為方法重用，其他的流程控制代碼在很多的地方要重寫，特別是當有兩個流程差不多的時候，代碼不可避免的重新寫。于是，這樣的類開始變得龐大而難以管理。

Active Record

這種組織方式已經是我們最熟悉的了。

在很多的項目中，我們的業務實體類基本和數據庫中表是一一對應的，例如一個Order業務類就是代表了數據庫中的Order表。而且在平時項目中，”樸實的三層(N層)”，一般都是基于這種方式在組織邏輯。

這種方式的***的區別就是每個業務類自己負責自己的數據存取，也就是說在業務類中包含了業務邏輯的處理和數據的存取。

例如：

public class Order  {      private Guid _id;      private DateTime _creationDate;      private int _shippingMethod;      private int _status;      private List<OrderItems> _orderItems;      public Guid Id      {          get { return _id; }          set { _id = value; }      }       public List<OrderItems> OrderItems      {          get { return _orderItems; }          set { _orderItems = value; }      }      // Business Logic      public void Place()      {          // Validate order based on business rules to ensure it is in          // a good state to add to the database          // Check for stock availablity on items ordered          this.Add();      }      public void Cancel()      {          // Check to ensure this order can be canceled.          this.Status = Status.Cancelled();          this.Save();      }       public void ProcessOrder()      {          // Check to ensure this order can be processed.          // Validate order based on business rules          // Udpate the stock levels of products ordered      }       // Data Access Methods      public void Save()      {          // Code to persist changes to the database      }       public void Add()      {          // Code to Add this object to the database      }       public void Delete()      {          // Code to remove this object from the database      }       public static List<Order> FindAll()      {          // Code to retrive all Orders from the database      }      public static Order FindBy(Guid id)      {          // Code to retrive a specific Order from the database      }  }

上面的代碼中，Order類包含了業務邏輯處理的代碼，如Cancel, Process。通過這些方法也調用了數據訪問代碼來保存數據。

如果在開發的項目中，業務類和數據表是一一對應的關系，例如在開發博客或者論壇，Active Record方式就很合適。

相信很多的項目都是基于這個方式在開發和組織邏輯層，這個方式***的弊端就是：數據庫表只要改動，那么業務邏輯層動，而且這種變動會一直波及到了UI那端。

Domain Model

通過用這種方式來組織業務層的時候，業務層就只是關注把現實中的概念轉換為相應的業務邏輯模型，不關注其他的方面。例如，在電子商務網站開發中，一些概念就被建模表示為一個個的業務模型(也就是業務類)，Order, Shopping Cart, Customer等。而且和Active Record***的區別就是：Domain Model中的業務類不是和表一一對應的，下圖就是一個很好的例子：

而且最主要的特點就是：每個業務類包含了很多的業務驗證，狀態跟蹤等。職責很單一，便于維護和理解。

示例代碼如下：

public class Order  {      private Guid _id;       public Guid Id      {          get { return _id; }          set { _id = value; }      }       public float ShippingCost()      {          return ShippingMethod.ShippingCostTo(this.DispatchAddress, this.ItemsTotalWeight());      }       public float Total()      {          return DiscountOffer.TotalPriceWithDiscountOfferAppliedTo(          this.Items, ShippingCost());      }       public void Process()      {          if (this.CanProcess())          {          // Charge the card          Customer.Card.Charge(this.Total());          // Set the status of the order          this.Status = Status.Shipped;          // Adjust the stock levels          foreach (OrderItem item in Items)          {              item.Product.DecreaseStockBy(item.QtyOrdered);                   }          else         {              throw new InvalidOrderStateForOperationException(              String.Format(              "Order {0} cannot be processed in its current state {1}",              this.Id, this.Status.ToString());          }      }       public bool CanProcess()      {          if (!this.Status == Status.Shipped && !this.Status = Status.Cancelled)          {              return (this.HasEnoughStockFor(me.Items) &&               GetBrokenRules.Count() == 0);          }          else         {              return false;          }      }       public List<BrokenBusinessRule> GetBrokenRules()      {          List<BrokenBusinessRule> brokenRules = new List<BrokenBusinessRule>();          if (Customer == null)              brokenRules.Add(new BrokenBusinessRule()              {                  Property = "Customer",                  Rule = "An Order must have a Customer"             });          else if (Customer.GetBrokenRules().Count > 0)          {              AddToBrokenRulesList(brokenRules, Customer.GetBrokenRules());          }          if (DispatchAddress == null)              brokenRules.Add(new BrokenBusinessRule()              {                  Property = "DispatchAddress",                  Rule = "An Order must have a Dispatch Address"             });          else if (DispatchAddress.GetBrokenRules().Count > 0)          {              AddToBrokenRulesList(brokenRules,              DispatchAddress.GetBrokenRules());          }          // ......          return brokenRules;      }  }

Order業務類的一部分代碼，但是從代碼中可以看出，這個類中包含了很豐富的業務邏輯。例如，在Process方法中，處理了下面的流程：

1．  調用CanProcess 方法來進行下面的驗證：

a.       Order的是否處于合適的可以被處理的狀態

b.       在Order中訂購的物品是否有足夠的庫存

2． customer用戶給這個order付款。至于怎么付款，這個邏輯就包含在了card類中。

3． 然后，對產品的庫存進行更新。

可以看出，采用Domain Model方式很適合來來組織復雜的業務邏輯，而且代碼也很容易閱讀和理解(如果在加上重構)。

看完上述內容是否對您有幫助呢？如果還想對相關知識有進一步的了解或閱讀更多相關文章，請關注億速云行業資訊頻道，感謝您對億速云的支持。