引言

  本文主要是参考Martion Fowler所著的《企业应用架构模式》与Eric Evans所著的《领域驱动设计》这两本泰山之作,加上本人在近年实际的工作过程中开发SOA系统所认识到的问题所写的一篇文章,欢迎各位点评。

  最后两节  细说应用层系统总体架构 是本文的重点,着重说明领域驱动设计与SOA之间的关系,对DDD有一定基础的朋友可以越过前面的几节,直接查看第七、八节。

  源代码下载 (数据库可以在.edmx文件根据模型生成)

  一、SOA与DDD的定义

  SOA与DDD都是常用的系统架构,但两者之间所针对的核心是不同的。

  SOA(面向服务架构)由Gartner在1996年提出来,它是一种分布式的软件架构,它可以根据需求通过网络对松散耦合的粗粒度应用组件进 行部署、组合和使用。简单来说,SOA就是一种大型系统开发的体系架构,在基于SOA架构的系统中,具体应用程序的功能是由一些松耦合并且具有统一接口的 组件(也就是service)组合构建起来的,它是针对多核心多平台之间的数据交换。

  DDD(领域驱动设计)由Eric Evans在2004提出,它的核心内容是“如何将业务领域概念映射到软件工程当中”。它推翻了“软件从数据层开发设计”的旧习惯,强调领域模型在软件中发挥的强大力量,注重如何把企业内部复杂的业务流程转化为软件。

  也许可以认为SOA针对的是大型系统的总体架构,注重如何把系统进行项目分离,隔离开发,最后实现系统合并。而DDD是针对单个项目的开发管理 过程,注重如何利用领域模型把业务需求转化为软件。两者之间并没有存在理论上的冲突,能把两者结合,各展所长,更能发挥各自的优势。

  二、DDD的分层结构

  1. 概念

  从概念上来说,领域驱动设计架构主要分为基础设施层、领域层、应用层、表现层4个概念层。

  基础结构层:是为各层提供各项通用技术能力而构建的,它可以为领域层提供像Hibernate、LINQ、ADO.NET等持久化机制,为应用层传递消息,为表现层提供插件等等。

  领域层:它是系统的核心部分,代表业务的逻辑概念。它会根据业务的实际流程定制了业务信息以及业务规则,并按一定的关系制定领域模型。领域模型 尽管需要依赖基础结构层进行保存,但领域模型之间的逻辑关系是跟基础结构层相隔离的。即使基础结构层从NHibernate技术转换成LINQ技术,也不 会影响到领域层的结构。领域模型只会依赖实际的业务逻辑,它只会根据业务的转变而灵活变动。

  应用层:它的任务是协调领域层与表现层之间的关系,也可以作为系统与外界沟通的桥梁,在这层里面不会包括任何的业务逻辑。在SOA面向服务架构,这一层起着重要的作用,在第七节将详细说明。

  表现层:它是常用的界面开发,可以以页面(ASP.NET、JSP),窗口(WinForm、WPF、Swing)等形式表现,它的主要职责是 负责与用户进行信息沟通。(注意:在一般的项目开发中,Web服务会作为与外界通讯的接口放置在表现层中,但在SOA中,Web服务会大多置于应用层中, 下面将会作进一步解释)

  2. 开发实例

  在此先举个常见的订单管理例子,在下面的章节里都会以这个实例为参考:

  每个用户在Person表里面都会有一个对应的帐户,里面记录了用户的姓名、地址、电话、积分(Point)等基本信息。

  在Order表里记录的是每次交易的过程,每次商品的送货费(Freightage)为10元,当商品价格(Price)超过98元可免费送 货,当用户Person积分(Point)超过2000分可获7折优惠(Favorable),1000~2000分可获8折,1000分以下可有9折, 最后总体价格为为(TotalPrice)。

  在最后结单的时候Order表里会产生订单号码OrderNumber和下订日期Delivery,Person表的积分也会加上订单总价的点数。

  最后OrderItem表包含了物品Goods、物品价格Price、购买数量Count等属性,它主要记录每次订单的详细交易状况。

  上面的业务逻辑跟淘宝、当当等等大型购物网基本相似。之所以用这样一个例子作为参考,是想表现一下DDD是如果利用领域模型去适应多变的业务逻辑关系。

  三、把业务关系转化为领域模型

  1. 概念

  模型驱动设计(MODEL-DRIVEN-DESIGN)是DDD里面的核心,它代表的是各个对象之间的关系,把复杂的逻辑关系转化为模型。

  模型主要分为实体(Entity)、值对象(Value Object)与服务(Service)三种。

  实体:实体所包含的不单止是一连串的属性,更重要的是与事件的联系,在一个生命周期中环境的变化与事件发生,将引起实体内部产生变化。好像在实 体Order里面,Person的积分(Point)和OrderItem的价格(Price)都会直接影响总体价格(TotalPrice)的大小,而 总体价格也会影响到运费Freightage的多少等等。在Order实体的一切,都会受到Person、OrderItem等这些外部因数的影响,这样 的对象被视为实体。在不同的时刻,实体会有不同的状态,所以在开发过程中我们需要为实体加上一个“标识符”来区分对象的身份,它是实体的生命周期里的唯一 标志。

  值对象:当所用到的对象只有属性而没有其他逻辑关系的时候,我们就可以把它视为是值对象。值对象没有状态,也不需要有 “标识符”。在多数情况下它可以作为一个属性存在于一个实体的内部。一般情况下值对象的属性是不可改变的,当需要更改属性时,可以把整个对象删除,然后重 新加入一个新对象。

  服务:当实体之间存在某些操作,它们并不单一地附属于某一个实体,而是跟多个实体都有关联的时候,就可以使用服务来封装这些操作。值得注意的是 服务并非单独指Web Service, 也并非单单存在于领域层,而是在各个层当中都会存在服务,每一层的服务都有着不同的职能。在基础结构层服务可能是用于构建身份验证、电子邮件、错误处理等 等操作;在领域层,服务更多时候是一种操作,它用于协调多个实体之间的关系,处理各类的业务问题;在应用层(特别是在分布式开发系统内),服务多以Web Service、TCP/IP套接字、MSMQ等等方式实现,服务在此处会作为一个与外界通讯的接口。

  • 备注 :这里面也存在一定的争义,Eric 认为实体所代表的只是多个对象之间的关系,而它们的动作将会由服务来体现出来,这被称为贫血型模型。但在开发过程中,越来越多人会把动作加入到实体里面, 这被称为充血型模型。其实不同的问题应该客观分析,分别对待,在这个例子里面将会以按照 Eric 的定义来开发服务,在后面的开发过程中大家也可以从中体现一下服务层所带来的好处。

  2. 实例说明

  先以ADO.NET Entity Framework实现模型,Person、Order分别属于两个实体,它们都将继承Root接口,在它们的生命周期内都会生成一个Guid作为标志。 此处把OrderItem作为一个值对象置于Order实体内,这意味着OrderItem会通过Order来获取,外界不能跨越Order直接获取 OrderItem。当然这应该由具体的业务情况来确定,当外界需要单独调用OrderItem类的时候,就应该考虑把OrderItem独立成为一个实 体类。

  在这里可利用分部类为实体增加Guid属性,关于分部类于分部方法的详细介绍可参考C#综合揭秘——分部类和分部方法

 Business.DomainModel
{
      Root {
    }

       Order:Root
    {  
         Guid _guid;        
        
         Order()
        {
            _guid = System.Guid.NewGuid();
        }

                 Guid GUID
        {
             {  _guid; }
        }
    }

       Person:Root
    {
         Person()
        {
            _guid = System.Guid.NewGuid();
        }

                 Guid _guid;

         Guid GUID
        {
             {  _guid; }
        }
    }
}

  四、细说Repository

  1. 概念

  Repository是把持久化对象转换成领域模型的一种方式,可用于获取、更新持久对象并管理它们的生命周期。它使应用程序与持久化技术实现解耦,程序无需受制于使用Oracle还是MySql数据库,也不会受到Hibernate、LINQ、ADO.NET等数据层的约束,使开发人员可以把注意力集中到领域模型当中。

  Repository与传统三层模式的DAL层有点相似,但Repository针对的是每一个根对象来划分边界的。在这个例子当中,Person与Order都会有对应的PersonRepository、OrderRepository。而OrderItem只是Order的子属性,所以它的插入、更新、删除都会包含在OrderRepository当中。当多个对象之间建立起联系后,关系将是复杂的,特别是在LINQ里面,程序可以轻易通过Person的导航属性里获取OrderItem的值,最后很容易使代码变得混乱。所以确立Repository的边界,可以在有效管理每个Repository的职能。

  2. 实例说明

  注意OrderItem的存取、删除都包含在OrderRepository里面。在获取、修改Order的时候,也会利用“显式加载” context.Order.Include("OrderItem") 的方法,使OrderItem实现同步更新。而通过PersonRepository.GetPerson(int)获取的Person对象,它内部的Order属性将是null值,这必须清晰按照领域模型的边界划分的。

  当LINQ面世以后,数据的获取变得简单,特别在一些小型的系统开发时,很多人会不自觉地把这种领域模型的分界规则打破。但随着系统的复杂化,问题就会逐渐呈现。比如当Order对象的属性被更新,使用OrderRepository.Update(Order)更新数据库后,页面的Person对象未能同步实现更新,在Person与数据库交换数据的时候,Order又被变回旧值。

  在混乱的数据层开发中,这种情况非常常见,所以在下会坚持Repository的原则,把Repository的职能清晰按照领域模型划分。

 Business.IRepository
{
      IOrderRepository
    {
        Order GetOrder( id);
        IList<Order> GetList();
        IList<Order> GetListByPerson( personID);
         AddOrder(Order order);
         DeleteOrder( id);
         UpdateOrder(Order order);
      
         AddOrderItem(OrderItem orderItem);
         DeleteOrderItem( id);
    }

      IPersonRepository
    {
         AddPerson(Person person);
         AttachPerson(Person person);
         UpdatePerson(Person person);
        Person GetPerson( id);
        IList<Person> GetList();
    }
}

 Business.Repository
{
      OrderRepository:IOrderRepository
    {
                 Order GetOrder( id)
        {
            BusinessContext _context =  BusinessContext();
            Order order = ;

            
            {
                 (TransactionScope scope =  TransactionScope())
                { 
                                         list = _context.Order.Include()
                        .Where(x => x.ID == id);
                     (list.Count() > )
                        order = list.First();
                    
                        order =  Order();
                    scope.Complete();
                }
            }
             (Exception ex)
            {
                                Business.Common.ExceptionManager.DataException.DealWith(ex);
                order =  Order();
            }
            _context.Dispose();
             order;
        }
        ..................
        ..................
    }

      PersonRepository:IPersonRepository
    {
          AddPerson(Person person)
        {
             LinqHelp.Add<Person>(person);
        }

         Person GetPerson( id)
        {
             LinqHelp.Get<Person>(id);
        }
        .................
        .................
    }
}

  在更新Order这种复杂的领域模型时,如果要分辨单个OrderItem属性是新建值还是更新值,然后分别处理,那将是比较麻烦的,而且OrderItem只是一个值对象,ID编码等属性对它没有任何实在意义。所以在更新List<OrderItem>属性时都会先把它全部删除,然后重新加载,在OrderItem数量不多的时候,这是一种十分有效的方法。

 Business.Repository
{
      OrderRepository:IOrderRepository
    {
         .................
         .................
                  UpdateOrder(Order order)
        {
             returnValue = -;
            BusinessContext _context =  BusinessContext();
           
            
            {
                 (TransactionScope scope =  TransactionScope())
                {
                     list = _context.Order.Include()
                        .Where(x => x.ID == order.ID);
                     (list.Count() > )
                    {
                                                Order _order = list.First();
                        _order.Count = order.Count;
                        _order.Delivery = order.Delivery;
                        _order.Favorable = order.Favorable;
                        _order.Freightage = order.Freightage;
                        _order.OrderNumber = order.OrderNumber;
                        _order.PersonID = order.PersonID;
                        _order.Price = order.Price;
                        _order.TotalPrice = order.TotalPrice;

                                                 (list.First().OrderItem.Count != )
                             ( item  list.First().OrderItem)
                                DeleteOrderItem(item.ID);
                                                 (order.OrderItem.Count != )
                        {
                             ( item  order.OrderItem)
                            {
                                 _orderItem =  OrderItem();
                                _orderItem.Count = item.Count;
                                _orderItem.Goods = item.Goods;
                                _orderItem.OrderID = item.OrderID;
                                _orderItem.Price = item.Price;
                                AddOrderItem(_orderItem);
                            }
                        }
                        returnValue = _context.SaveChanges();
                    }
                    
                        returnValue = ;

                    scope.Complete();
                }
            }
             (Exception ex)
            {
                Business.Common.ExceptionManager.DataException.DealWith(ex);
                returnValue=-;
            }

            _context.Dispose();
             returnValue;
        }

                  AddOrderItem(OrderItem orderItem)
        {
             LinqHelp.Add<OrderItem>(orderItem);
        }

                  DeleteOrderItem( id)
        {
            EntityKey key =  EntityKey(, , id);
             LinqHelp.Delete(key);
        }
    }
}

  五、领域层的服务

  1. 例子说明

  在第二节已基本介绍过服务的作用了,领域层服务的作用主要是为了解决业务上的逻辑问题,更多的时候,服务是一个与业务相关的动作。比如在上述例子中:

  在Order表里记录的是每次交易的过程,每次商品的送货费(Freightage)为10元,当商品价格(Price)超过98元可免费送货,当用户 Person积分(Point)超过2000分可获7折优惠(Favorable),1000~2000分可获8折,1000分以下可有9折,最后总体价 格为为(TotalPrice)。

  这复杂的业务逻辑,完全可以由一个领域服务类AccountManager来完成

 Business.Service.DomainService
{
      AccountManager
    {
         Person _person;
         Order _order;

         AccountManager(Person person, Order order)
        {
            _person = person;
            _order = order;
        }

                  Account()
        {
                        GoodsCount();
                        PriceAccount();
                        FavorableAccount();
             price1 = (_order.Price - _order.Favorable).Value;
                        FreightageAccount(price1);
                        _order.TotalPrice = price1 + _order.Freightage.Value;
        }

                  GoodsCount()
        {
            _order.Count=;
             ( OrderItem  _order.OrderItem)
                _order.Count += OrderItem.Count;
        }
 
                  PriceAccount()
        {
            _order.Price = ;
             ( OrderItem  _order.OrderItem)
                _order.Price += OrderItem.Price * OrderItem.Count;
        }

                  FavorableAccount()
        {
             point = ()_person.Point.GetInt();

             (point < )
                _order.Favorable = _order.Price * ;
             (point >=  && point < )
                _order.Favorable = _order.Price * ;
             (point > )
                _order.Favorable = _order.Price * ;
        }

                  FreightageAccount( price)
        {
             (price >= )
                _order.Freightage = ;
            
                _order.Freightage = ;
        }
    }
}

  你可能会说,在这个业务流程中,除了积分优惠Person.Point以外,其他的业务都只与Order的属性有关,按照充血型模型的方案,完全可以把这些业务放到Order的方法当中,而把积分优惠独立成为一个服务。但在下在很多的开发过程中发现,为模型附上动作会带来一连串的问题,好像你不知道哪些操作应该在模型动作上实现,哪里应该在服务中实现......。对于这些无休止的争论不会因为这里的一个小例子而停止,但在这里我会坚持使用贫血型模型,利用服务来完成所有的动作。

  再举一个例子:在最后结单的时候Order表里会产生订单号码OrderNumber和下订日期Delivery,Person表的积分也会加上订单总价的点数。对应这个操作,也可以单独开发一个PaymentManager服务类进行管理。

 Business.Service.DomainService
{
      PaymentManager
    {
                  Payment(Order order)
        {
                        OrderManager orderManager =  OrderManager();
            order.OrderNumber = Guid.NewGuid().ToString();
            order.Delivery = DateTime.Now;
            orderManager.UpdateOrder(order);
                        PersonManager personManager =  PersonManager();
            personManager.AddPoint(order.PersonID, ()order.TotalPrice);
        }
    }
}

  利用领域层的服务,使得每个Manager服务类的职能非常明确,业务管理起来也十分地方便,领域层可以随着业务的改变而灵活变动。最后加上实体基本的插入、更新、获取等等操作,领域层的服务就可以清晰地完成。

  可以注意到每次加入新Order,或者更新Order的时候,都会调用到AccountManager对象来重新计算费用

 Business.Service.DomainService
{
      OrderManager
    {
         IOrderRepository orderRepository = DataAccess.CreateOrderRepository();

          AddOrder(Order order)
        {
                        Account(order);
                         orderRepository.AddOrder(order);
        }

          UpdateOrder(Order order)
        {
            Account(order);
             orderRepository.UpdateOrder(order);
        }

          AddOrderItem(OrderItem orderItem)
        {
             index = orderRepository.AddOrderItem(orderItem);
            Order order = orderRepository.GetOrder(orderItem.OrderID);
            UpdateOrder(order);
             index;
        }

          DeleteOrderItem(OrderItem orderItem)
        {
             index = orderRepository.DeleteOrderItem(orderItem.ID);
            Order order = orderRepository.GetOrder(orderItem.OrderID);
            UpdateOrder(order);
             index;
        }

                  Account(Order order)
        {
                        IPersonRepository personRepository = DataAccess.CreatePersonRepository();
            Person person = personRepository.GetPerson(order.PersonID);

                        AccountManager accountManager =  AccountManager(person, order);
            accountManager.Account();    
        }

          DeleteOrder(Order order)
        {
             orderRepository.DeleteOrder(order.ID);
        }
        ..................
        ..................
    }

      PersonManager
    {
         IPersonRepository personRepository = DataAccess.CreatePersonRepository();

          AddPerson(Person person)
        {
             personRepository.AddPerson(person);
        }

                  AddPoint( personID, point)
        {
            Person person = personRepository.GetPerson(personID);
            person.Point=person.Point.GetInt()+point;
             personRepository.UpdatePerson(person);
        }
        ...............
        ...............
    }
}

  六、工厂模式Factory

  Factory是常用到软件开发模式,在网上像简单工厂、工厂方法、抽象工厂等开发模式的资料都到处可寻,可这并不是领域驱动设计的主题。在这一节里,我主要想介绍Factory的适用时机。

  并非生成所有对象的时候,都需要用到工厂模式。在生成简单对象的时候,可以直接利用构造函数来代替工厂,也可以添加工厂方法来生成对象。但如果在生成对象时,内部属性之间存在一系统复杂的业务规则的时候,就可以把生成方法独立到一个Factory类里面。这时候客户端无需理会潜在逻辑关系,而直接通过这个Factory来生成相应的对象。

  举个例子,在新建Order的时候,业务上规定运费是总体金额的1%,折扣规定是7.5折...... 。如果由客户端新建一个对象Order,然后为这些属性赋值,那相关的业务逻辑就会暴露在外。这时候就可以使用Factory模式,把属性之间的关系封装到Factory之内,客户端通过Factory就能轻松地生成Order对象而无需要理会复杂的内部关系。

  至于较复杂的Factory模式,在此不多作介绍,各位可以在网上查找相关资料。

  七、细说应用层

  1. SOA系统中应用层的特点

  在开发SOA分布式系统的时候,应用层是一个重点,它是一个运输中心和信息发放的端口,担负着数据转换与数据收发的责任。它有以下的特点:

  • 单一性

  应用层只是一个接驳信息的桥梁,当中不应该包含任何业务逻辑的成分,任何与业务有关元素都应该封装在领域层。

  • 粗粒度

  分布式系统与普通网站和应用程序不同,因为它假定外界对系统内部是毫无了解的,用户只想输入相关数据,最后得到一系列计算结果。所以我们应该把计算结果封装在一个数据传输对象(DTO)内,实现粗粒度的传递,这是一般项目与SOA系统在服务层的一个最明显的差别。 想想如果一个页面需要同时显示一个顾客的个人资料、某张订单的详细资料,那将要同时获取Person、Order、OrderItem三张表的信息。在普通系统的开发过程中,这并不会造成太大问题,但在使用远程服务的时候,如果用三个方法分别获取,那将会造成不少的性能损耗。特别是在分布式开发系统中,应用层与表现层之间是实现分离的,更多时候两者是由不同部门所开发的模块,表现层不会了解应用层中的逻辑关系,Person,Order,OrderItem三样东西在表现层看来,也就是同一样东西,那就是返回值。所以在系统内,应该把多张表的信息封装在一个DTO对象内,通过应用层一个远程方法一次性返还。使用粗粒度的数据元素是分布式系统的一个特点。

  • 传输性

  如果你熟悉SOA系统,对DTO(Data Transfer Object 数据传输对象)这个词一定并不陌生。DTO属于一个数据传输的载体,内部并不存在任何业务逻辑,通过DTO可以把内部的领域对象与外界隔离。DTO所封装的是客户端的数据,所以它的设计更多地是针对客户端的需求,而不是业务逻辑。比如说本来Person与Order是一对多的关系,但当一个页面只要显示的是一个客户的单张订单信息,那我们就可以根据需要把DTO中的Person和Order设计为一对一的关系。如果你是使用MVC开发一般的网站,更多时候会把返回对象直接转化为Model。如果你开发是一个分布式系统,那更多时候会从系统性能与隐藏业务逻辑出发着想。而且考虑到把内部对象转化为DTO,将是一件麻烦的事,建议应该考虑DTO的兼容性,使DTO可以作为多个方法的返还载体。(注意:在SOA系统内,应该从性能出发优先考虑粗粒度元素的传输性问题)

  • 封装性

  应用层并不需要复杂的模型,只需把一些功能封装在少数的几个应用层服务类里面,使用Web Service、TCP/IP套接字、MSMQ等服务方式向外界发布。

  说到这里,我真的十分感激Martin先生带给我的帮助,在开发过程中,这些复杂的问题带给我不少的困扰,Martin先生一纸富有经验的独特见解,真的带给在下很大的启发。

  2. 应用层的协调性

  应用层服务会利用Repository,完成实体基本的插入、更新、获取等等操作,并调用领域层的服务管理的业务逻辑。注意观察,一切的业务逻辑都只会隐藏于领域层,应用层服务只起着协调作用,本身不应该包含有任何业务逻辑。

  可以看到OrderService就是通过调用AccountManager、PaymentManager等领域层服务来完成结账、付款等一系列复杂业务逻辑的。

 Business.Service.ApplicationService
{
      PersonService
    {
         IPersonRepository personRepository = DataAccess.CreatePersonRepository();

          AddPerson(Person person)
        {
             personRepository.AddPerson(person);
        }

          UpdatePerson(Person person)
        {
             personRepository.UpdatePerson(person);
        }

         Person GetPerson( personID)
        {
             personRepository.GetPerson(personID);
        }

         IList<Person> GetList()
        {
             personRepository.GetList();
        }
    }

   OrderService
 {
         IOrderRepository orderRepository = DataAccess.CreateOrderRepository();

          AddOrder(Order order)
        {
                        Account(order);
                         orderRepository.AddOrder(order);
        }

                  Account(Order order)
        {
                        IPersonRepository personRepository = DataAccess.CreatePersonRepository();
            Person person = personRepository.GetPerson(order.PersonID);

                        AccountManager accountManager =  AccountManager(person, order);
            accountManager.Account();    
        }

                 Order Payment( orderID)
        {
             order=orderRepository.GetOrder(orderID);
             (order != )
            {
                PersonRepository personRepository =  PersonRepository();
                 person=personRepository.GetPerson(order.PersonID);

                PaymentManager paymentManager =  PaymentManager();
                paymentManager.Payment(order, person);

                orderRepository.UpdateOrder(order);
                personRepository.UpdatePerson(person);

                 order;
            }
            
                  Exception();
        }

          DeleteOrder(Order order)
        {
             orderRepository.DeleteOrder(order.ID);
        }

         Order GetOrder( orderID)
        {
             orderRepository.GetOrder(orderID);
        }

         IList<Order> GetList()
        {
             orderRepository.GetList();
        }

         IList<Order> GetListByPerson( personID)
        {
             orderRepository.GetListByPerson(personID);
        }

          UpdateOrder(Order order)
        {
            Account(order);
             orderRepository.UpdateOrder(order);
        }

          AddOrderItem(OrderItem orderItem)
        {
             index = orderRepository.AddOrderItem(orderItem);
            Order order = orderRepository.GetOrder(orderItem.OrderID);
            UpdateOrder(order);
             index;
        }

          DeleteOrderItem(OrderItem orderItem)
        {
             index = orderRepository.DeleteOrderItem(orderItem.ID);
            Order order = orderRepository.GetOrder(orderItem.OrderID);
            UpdateOrder(order);
             index;
        }
        .......................
        .......................
    }
}

  3. 数据转换过程

  实现领域对象与DTO之间的转换是一件复杂的事件,因此可以建立一个数据转换器实现此功能。

  在平常的工作里,不太多会把“订单管理系统”做成SOA的模式,因为在分布式系统中,数据的格式与定义大多数由部门之间协定,其中包含明确的规则。但由于条件的局限,在这里还是想以订单管理为例子,希望可以带给你一定的帮助。在购物车结账,页面会包含用户基本信息,当前订单信息,订单明细信息等多个部分。

  首先可以根据页面建立DTO对象,在分布式系统中,通常会把DTO对象放在一个独立的命名空间里,在这个实例里面称之为Business.TransferObject。DTO对象更多时候是面向表现层的需求而建立,这里由于表现层页面所需要的只是单个用户,单张订单的数据,所以在OrderDTO对象里会包含了用户信息和订单资料,也存在订单详细列List<OrderItemDTO>。当然,DTO的设计可以随着需求而修改。

  在SOA系统里,DTO是远程服务数据的载体,所以会把DTO附上可序列化特性,这此例子中会使用WCF的数据契约实现OrderDTO和OrderItemDTO。

  这里OperationAssembler就是一个数据转换器,它是数据转换的核心,它是领域对象与DTO之间实现转换的工具。要在多个对象之间实现数据转换实在是一件非常麻烦的事,所以我一直提倡注意DTO对象的兼容性,使单个DTO对象可以适用于多个外观层,以减少数据转换所带来的麻烦。

 Business.Service.ApplicationService
{
      OperationAssembler
    {
                  OrderDTO GetOrderDTO(Order order,Person person)
        {
            OrderDTO orderDTO =  OrderDTO();
             (person != )
            {
                orderDTO.EMail = person.EMail.GetString();
                orderDTO.Address = person.Address.GetString();
                orderDTO.Name = person.Name.GetString();
                orderDTO.PersonID = person.ID;
                orderDTO.Point = person.Point.GetInt();
                orderDTO.Telephone = person.Telephone.GetString();
            }
             (order != )
            {
                orderDTO.PersonID = order.PersonID;
                orderDTO.Count = order.Count.GetInt();
                orderDTO.Delivery = order.Delivery.GetDateTime();
                orderDTO.Favorable = order.Favorable.GetDouble();
                orderDTO.Freightage = order.Freightage.GetDouble();
                orderDTO.OrderID = order.ID;
                orderDTO.OrderNumber = order.OrderNumber.GetString();
                orderDTO.Price = order.Price.GetDouble();
                orderDTO.TotalPrice = order.TotalPrice.GetDouble();
                 orderItemList = order.OrderItem.ToList();
                 (orderItemList.Count != )
                {
                     orderItemDTO =  List<OrderItemDTO>();
                     ( orderItem  orderItemList)
                        orderItemDTO.Add(GetOrderItemDTO(orderItem));
                    orderDTO.OrderItemList = orderItemDTO;
                }
            }
             orderDTO;
        }

          OrderItemDTO GetOrderItemDTO(OrderItem orderItem)
        {
            OrderItemDTO orderItemDTO =  OrderItemDTO();
            orderItemDTO.Count = orderItem.Count.GetInt();
            orderItemDTO.Goods = orderItem.Goods.GetString();
            orderItemDTO.OrderID = orderItem.OrderID;
            orderItemDTO.OrderItemID = orderItem.ID;
            orderItemDTO.Price = orderItem.Price.GetDouble();
             orderItemDTO;
        }

                   SetOrder(OrderDTO orderDTO,  Person person,  Order order)
        {
            person =  Person();
            person.EntityKey= System.Data.EntityKey(,,orderDTO.PersonID);
            person.Address = orderDTO.Address;
            person.EMail = orderDTO.EMail;
            person.ID = orderDTO.PersonID;
            person.Name = orderDTO.Name;
            person.Point = orderDTO.Point;
            person.Telephone = orderDTO.Telephone;

            order =  Order();
            order.EntityKey= System.Data.EntityKey(,,orderDTO.OrderID);
            order.Count = orderDTO.Count;
             (orderDTO.Delivery.Year!=&&orderDTO.Delivery.Year!=)
                order.Delivery = orderDTO.Delivery;
            order.Favorable = orderDTO.Favorable;
            order.Freightage = orderDTO.Freightage;
            order.ID = orderDTO.OrderID;
            order.OrderNumber = orderDTO.OrderNumber;
            order.PersonID = orderDTO.PersonID;
            order.Price = orderDTO.Price;
            order.TotalPrice = orderDTO.TotalPrice;
             orderItemDTOList = orderDTO.OrderItemList;
             (orderItemDTOList.Count() != )
                 ( orderItemDTO  orderItemDTOList)
                    order.OrderItem.Add(GetOrderItem(orderItemDTO));
        }

          OrderItem GetOrderItem(OrderItemDTO orderItemDTO)
        {
            OrderItem orderItem =  OrderItem();
            orderItem.EntityKey =  System.Data.EntityKey(, , orderItemDTO.OrderItemID);
            orderItem.Count = orderItemDTO.Count;
            orderItem.Goods = orderItemDTO.Goods;
            orderItem.ID = orderItemDTO.OrderItemID;
            orderItem.OrderID = orderItemDTO.OrderID;
            orderItem.Price = orderItemDTO.Price;
             orderItem;
        }
    }
}

 Business.TransferObject
{
    [DataContract]
      OrderItemDTO
    {
          _orderItemID;
          _orderID;
          _goods;
          _price;
          _count;

        [DataMember]
          OrderItemID
        {
             {  _orderItemID; }
             { _orderItemID = value; }
        }
        ............
        ............
    }

    [DataContract]
      OrderDTO
    {
          _personID;
          _name;
          _address;
          _telephone;
          _point;
          _email;
          _orderID;
          _orderNumber;
          _count;
          _freightage;
          _favorable;
         DateTime _delivery;
          _price;
          _totalPrice;
         IList<OrderItemDTO> _orderItemDTOList;

        [DataMember]
          PersonID
        {
            { ._personID;}
            {._personID=value;}
        }
        ..........
        ..........
    }
}

  4. 应用层的发布

  在开发SOA系统的时候,应用层的服务需要使用远程方法对外开放,在接收到请求的时候,它可以调用领域层服务获取运算结果,然后通过数据转换器OperationAssembler把运算结果转换成DTO,最后返还到表现层。在起初,我曾尝试对应每个应用层的对象建立一个远程接口,但经过多次重构以后,我觉得行程对象就是一个简单的对外接口,对象之间不存在什么逻辑关系。所以更简单的方法是使用外观模式,建立少数的几个远程服务类,把所有的应用层对象的方法都包含在内。

  可以留意代码,OperationService包括了对Person模型和Order模型的所有操作。而且每个操作都只是简单地调用领域层服务 (DomainService) 获得计算结果,然后使用数据转换器 (OperationAssembler)转换数据,当中并不存在任何的业务逻辑。

 Business.Service.ApplicationService
{
    [ServiceContract]
      IOperationService
    {
        [OperationContract]
         AddOrder( OrderDTO orderDTO);

        [OperationContract]
         DeleteOrder(OrderDTO orderDTO);

        [OperationContract]
         UpdateOrder( OrderDTO orderDTO);

        [OperationContract]
        IList<OrderDTO> GetOrderByPerson( personID);

        [OperationContract]
        OrderDTO GetOrder( orderID);

        [OperationContract]
         AddPerson( OrderDTO orderDTO);

        [OperationContract]
         UpdatePerson( OrderDTO orderDTO);

        [OperationContract]
        OrderDTO GetPerson( personID);

        [OperationContract]
        IList<OrderDTO> GetPersonList();
    }
}

 Business.Service.ApplicationService
{
      OperationService:IOperationService
    {
        [OperationBehavior(TransactionScopeRequired = , TransactionAutoComplete = )]
          AddOrder( OrderDTO orderDTO)
        {
            OrderManager orderManager =  OrderManager();
            Order order = GetOrder(orderDTO);
             n = orderManager.AddOrder(order);
            orderDTO = OperationAssembler.GetOrderDTO(order, );
             n;
        }

        [OperationBehavior(TransactionScopeRequired = , TransactionAutoComplete = )]
          DeleteOrder(OrderDTO orderDTO)
        {
            OrderManager orderManager =  OrderManager();
             orderManager.DeleteOrder(GetOrder(orderDTO));
        }
        ....................
        ....................
    }
}

  八、系统总体架构

  1. 体现领域驱动设计的架构

  到此总结一下领域驱动设计DDD的总体结构,Repository先使用ORM映射或SQL命令等方式把持久化数据转化为领域对象,然后根据业务逻辑把动作转化为领域层的服务(Domain Service),操作过程中所针对的都是领域对象Domain Object 。接着,应用层通过数据转换器把领域对象Domain Object转化为数据传输对象DTO,再利用应用层的服务(Application Service)开通对外的接口,最后表现层通过远程调用获取数据。

  注意留意的是SOA系统中,UI表现层与Application Service应用层服务是实现分离的,表现层可以同时调用多方的远程服务来完成工作。

  2. 体现面向服务开发的架构

  面向服务开发SOA的架构主要体现在表现层与应用层之间通过远程通讯实现分离,表现层可以引用多方的应用服务作为基础。由此系统实现业务上的分离,不同的功能模块可以独立开发,最后通过服务在表现层共同体现。长期的发展,使不少的企业针对单个功能模块开发出一套独立的系统,再通过强大的虚拟化技术为第三方提供服务,这就是云计算的前身。

  就像一个通讯购物的平台,其实就是综合了内部业务管理、银行转帐服务、呼叫中心、第三方接口等多方服务的综合性平台。如果你有过这方面的经验,就会知道其实银行转帐、呼叫中心不过就是银行、电信、移动等公司提供的几个简单的接口。开发人员根本无需理会其实内部的结构,只要通过几个简单的远程方法就能调用。这正是应用层服务 Application Service 的最好体现。

  3. 结束语

  写这篇文章目的只是想与各位分享一下我在开发过程中的一些体会,欢迎各位点评,指出其中的不足。

  其实架构是死物,人才是有脑子的生物。每一个架构必然会有其优点,也会有不足之处,我们应该从开发之中一齐起来体验,而不是盲目地跟从,希望在下的拙见能够给大家带来帮助。可别忘了支持一下,挺一挺。

  源代码下载 (数据库可以在.edmx文件根据模型生成)

  相关文章

  SOA的概念

  SOA基本架构  

  作者:风尘浪子



转自 http://kb.cnblogs.com/page/124969/