走向.NET架构设计―第四章―业务层分层架构（后篇）

走向.NET 架构设计― 第四章― 业务层分层架构（后篇）

　　前言： 在上一篇文章中，我们讨论了组织业务逻辑的模式：Transaction Script 和Active Record ，Domain Model 。在本篇中开始讲述Anemic Model 。

      今天的内容比较简单，也是本章的一个收尾！

 

本篇议题如下：

Transaction Scrip( 前篇)

Active Record 前篇)

Domain Model （中篇）

Anemic Model （后篇）

DDD （后篇）

 

　

　 

　　Anemic Domain Model ：

     初看起来，贫血型领域模型和Domain Model 模式很像。但是它们确实是不同的：Domain Model 的领域类中包含了自身的业务逻辑和数据，以及对象之前的关系；Anemic Domain Model 的领域类将与自身相关的业务处理逻辑全部转移到了模型之外――有专门的业务规则类，这使领域类成为了一个简单的数据对象。

      这种模式的缺点就是：领域服务类中的代码更加结构化了，和Transaction Script 模式很像，这也就会带来和Transaction Script 模式一样的问题。例如，其中一个就是违背了“Tell, Don ’t Ask ”原则：业务对象原本应该告诉客户代码它们是否能执行某个操作，而不是让客户代码根据业务对象的状态来自己判断是否该执行，现在因为所有逻辑已经从业务类中移出了，业务类已经没有 “自主能力”了。

       如果采用Anemic Domain Model 来实现前面的订单处理相关例子，Order 业务类的代码则如下所示：

 

  public  class Order
    {
         public  string OrderNo {  get;  set; }
         public OrderStatus Status {  get;  set; }
         public List<OrderItem> Items {  get;  set; }        
    }

 

复制代码

   Order 的业务规则会放在特定的规则类中，如下所示：

 

public  class PorcessStatusSpecification
    {       
         public  bool IsSatisfiedBy(Order order)
        {
             return order.Status != OrderStatus.Processed;
        }
    }

复制代码

 

现在 OrderService 领域服务类的方法如下所示：

 

 

public  bool OrderProcess(Order requestOrder)
     {
             bool result =  false;
             var order = requestOrder;
            ProductService productService =  null;

             if (order !=  null)
            {
                PorcessStatusSpecification specification =  new PorcessStatusSpecification();
                 if (specification.IsSatisfiedBy(order))
                {
                    productService =  new ProductService();
                     var hasInventory = productService.CheckInventory(order);
                     if (hasInventory)
                    {
                        order.Status = OrderStatus.Processed;
                         // ...
                    }
                }
            }

             return result;
     }

 

复制代码

　 从上面的代码可以看出：OrderService 完全取代了原本的Order ，而且还会为Order 修改状态。随着逻辑的复杂性增强，在服务类中会出现很多的辅助方法，这会导致服务类最后和Transaction Script 一样变得无法维护。　

  到这里为止，四种组织业务逻辑的模式就讲述完了，每一种都有自己的用途，无所谓“一定用，或者一定不用”。到底是用哪种，都是根据项目和经验而定。

 

　　DDD ：

　　下面我们就来进入 DDD ，这里只是讲述了一下 DDD 中的一些基本概念，至于具体的讲述 DDD ：

　　1.       后面的章节会陆续的介绍

　　2.       阅读《领域驱动设计 . 软件核心复杂性应对之道》，如果朋友们有需要，留下自己的 Email ，我会发送给大家。

　　下面的一些的文字都是摘自一些书籍。目的只是一个为了让大家快速的了解一下DDD 。

　　DDD几个概念：

　　分层架构

　　实体

　　值对象

　　服务

　　模块

　　聚合

　　工厂

 

 

　　分层架构

 

　　当我们创建一个软件应用时，这个应用的很大一部分是不能直接跟 领域关联的，但它们是基础设施的一部分或者是为软件服务的。最 好能让应用中的领域部分尽可能少地和其他的部分掺杂在一起，因 为一个典型的应用包含了很多和数据库访问，文件或网络访问以及 用户界面等相关的代码。

 

　　在一个面向对象的程序中，用户界面、数据库以及其他支持性代码 经常被直接写到业务对象中。附加的业务逻辑被嵌入到 UI 组件和数 据库脚本的行为中。之所以这样做的某些原因是这样可以很容易地 让事情快速工作起来。

 

　　但是，当领域相关的代码被混入到其他层时，要阅读和思考它也变 得极其困难。表面看上去是对 UI 的修改，却变成了对业务逻辑的修 改。对业务规则的变更可能需要谨慎跟踪用户界面层代码、数据库 代码以及其他程序元素。实现粘连在了一起，模型驱动对象于是变 得不再可行。也很难使用自动化测试。对于每个活动中涉及到的技 术和逻辑，程序必须保持简单，否则就会变得很难理解。 因此， 将一个复杂的程序切分成层。开发每一个层中内聚的设计， 让每个层仅依赖于它底下的那层。遵照标准的架构模式以提供层的 低耦合。将领域模型相关的代码集中到一个层中，把它从用户界 面、应用和基础设施代码中分隔开来。释放领域对象的显示自己、 保存自己、管理应用任务等职责，让它专注于展现领域模型。这会 让一个模型进一步富含知识，更清晰地捕获基础的业务知识，让它 们正常工作。

 

　　一个通用领域驱动设计的架构性解决方案包含 4 个概念层：

 

　　将应用划分成分离的层并建立层间的交换规则很重要。如果代码没 有被清晰隔离到某层中，它会迅即混乱，因为它变得非常难以管理 变更。在某处对代码的一个简单修改会对其他地方的代码造成不可 估量的结果。领域层应该关注核心的领域问题。它应该不涉及基础 设施类的活动。用户界面既不跟业务逻辑紧密捆绑也不包含通常属 于基础设施层的任务。在很多情况下应用层是必要的。它会成为业 务逻辑之上的管理者，用来监督和协调应用的整个活动。

 

 

　　例如，对一个典型的交互型应用，领域和基础设施层看上去会这 样：用户希望预定一个飞行路线，要求用一个应用层中的应用服务 来完成。应用依次从基础设施中取得相关的领域对象，调用它们的 相关方法，比如检查与另一个已经被预定的飞行线路的安全边界。 当领域对象执行完所有的检查并修改了它们的状态决定后，应用服

务将对象持久化到基础设施中。  

 

　　实体

　　有一类对象看上去好像拥有标识符，它的标识符在历经软件的各种 状态后仍能保持一致。对这些对象来讲这已经不再是它们关心的属 性，这意味着能够跨越系统的生命周期甚至能超越软件系统的一系 列的延续性和标识符。我们把这样的对象称为实体。

 

　　OOP 语言会把对象的实例放于内存，它们对每个对象会保持一个对像 引用或者是记录一个对象地址。在给定的某个时刻，这种引用对 每一个对象而言是唯一的，但是很难保证在不确定的某个时间段它 也是如此。实际上恰恰相反。对象经常被移出或者移回内存，它被 序列化后在网络上传输，然后在另一端被重新建立，或者它们都被 消除。在程序的运行环境中，那个看起来像标识符的引用关系其实 并不是我们在谈论的标识符。

 

　　如果有一个存放了天气信息（如温度）的类，很容易产生同一个类 的不同实例，这两个实例都包含了同样的值，这两个对象是完全相 当的，可以用其中一个跟另一个交换，但它们拥有不同的引用，它 们不是实体。 如果我们要用软件程序实现一个“人”的概念，我们可能会创建一 个 Person 类，这个类会带有一系列的属性，如：名称，出生日期， 出生地等。这些属性中有哪个可以作为 Person 的标识符吗？名字不 可以作为标识符，因为可能有很多人拥有同一个名字。如果我们只

考虑两个人的名字的话，我们不能使用同一个名字来区分他们两 个。我们也不能使用出生日期作为标识符，因为会有很多人出在同 一天出生。同样也不能用出生地作为标识符。一个对象必须与其他 的对象区分开来，即使是它们拥有着相同的属性。错误的标识符可 能会导致数据混乱。

 

　　考虑一下一个银行会计系统。每一个账户拥有它自己的数字码。每 一个账户可以用它的数字码来精确标识。这个数字码在系统的生命 周期中会保持不变，并保证延续性。账户码可以作为一个对象存在 于内存中，也可以被在内存中销毁，发送到数据库中。当这个账户 被关闭时，它还可以被归档，只要还有人对它感兴趣，它就依然在 某处存在。不论它的表现形式如何，数字码会保持一致。 因此，在软件中实现实体意味着创建标识符。对一个人而言，其标 识符可能是属性的组合：名称，出生日期，出生地，父母名称、当 前地址。在美国，社会保险号也会用来创建标识符。对一个银行账 户来说，账号看上去已经足可以作为标识符了。通常标识符或是对

象的一个属性（或属性的组合），一个专门为保存和表现标识符而 创建的属性，也或是一种行为。对两个拥有不同标识符的对象来 说，能用系统轻易地把它们区分开来，或者两个使用了相同标识符 对象能被系统看成是相同的，这些都是非常重要的。如果不能满 足这个条件，整个系统可能是有问题的。

 

　　有很多不同的方式来为每一个对象创建一个唯一的标识符：可能由 一个模型来自动产生 ID ，在软件中内部使用，不会让它对用户可 见；它可能是数据库表的一个主键，会被保证在数据库中是唯一 的。只要对象从数据库中被检索，它的 ID 就会被检索出并在内存中 被重建； ID 也可能由用户创建，例如每个机场会有一个关联的代

码。每个机场拥有一个唯一的字符串 ID ，这个字符串是在世界范围 内通用的，被世界上的每一个旅行代理使用以标识它们的旅行计划 中涉及的机场。另一种解决方案是使用对象的属性来创建标识符， 当这个属性不足以代表标识符时，另一个属性就会被加入以帮助确 定每一个对象。

 

　　当一个对象可以用其标识符而不是它的属性来区分时，可以将它作 为模型中的主要定义。保证类定义简洁并关注生命周期的延续性和 可标识性。对每个对象定义一个有意义的区分，而不管它的形式或 者历史。警惕要求使用属性匹配对象的需求。定义一个可以保证对 每一个对象产生一个唯一的结果的操作，这个过程可能需要某个符 号以保证唯一性。这意味着标识可以来自外部，或者它可以是由系 统产生、使用任意的标识符，但它必须符合模型中的身份差别。模型 必须定义哪些被看作同一事物。

　　实体是领域模型中非常重要的对象，并且它们应该在建模过程开始 时就被考虑。决定一个对象是否需要成为一个实体也很重要，这会 在下一个模型中被讨论。

　　 

　　由于篇幅的原因，这里也不过多的写了，大家可以先下载 DDD的精简版 看看，需要的话，留下 Email ，我给出 DDD 的完整版！

 

　　今天就到这里了，还是希望多多见谅，支持！谢谢啊！

0人

了这篇文章

类别： 走向.NET架构设计┆阅读( 0)┆评论( 0) ┆ 返回博主首页┆ 返回博客首页

上一篇 走向.NET架构设计―第四章―业务层分层架构（.. 下一篇 走向.NET架构设计―第五章―业务层模式，原则..