如何浅析架构设计的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;      public Guid Id      {          get { return _id; }          set { _id = value; }      }       public List 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 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 GetBrokenRules()      {          List brokenRules = new List();          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方式很适合来来组织复杂的业务逻辑，而且代码也很容易阅读和理解(如果在加上重构)。

看完上述内容是否对您有帮助呢？如果还想对相关知识有进一步的了解或阅读更多相关文章，请关注行业资讯频道，感谢您对的支持。