我的“第一次”，就这样没了：DDD（领域驱动设计）理论结合实践

写在前面插一句：本人超爱落网-《平凡的世界》这一期，分享给大家。阅读目录：关于DDD 前期分析框架搭建代码实现开源-发布后记第一次听你，清风吹送，田野

写在前面

　　　　　　插一句：本人超爱落网-《平凡的世界》这一期，分享给大家。

　　阅读目录：

关于DDD
前期分析
框架搭建
代码实现
开源-发布
后记

第一次听你，清风吹送，田野短笛；第一次看你，半弯新湖，鱼跃翠堤；第一次念你，燕飞巢冷，释怀记忆；第一次梦你，云翔海岛，轮渡迤逦；第一次认你，怨江别续，草桥知己；第一次怕你，命悬一线，遗憾禁忌；第一次悟你，千年菩提，生死一起。

　　人生有很多的第一次：小时候第一次牙牙学语、第一次学蹒跚学步。。。长大后第一次上课、第一次逃课、第一次骑自行车、第一次懂事、第一次和喜欢的人说“我爱你”、第一次旅行、第一次敞开心扉去认识这个世界。。。

　　第一次的感觉：有甜蜜、有辛酸；有勇敢、有羞涩；有成功、有失败。不管怎样，都要勇敢的迈出第一步，不论成功与失败，至少自己努力过，证明过自己就好，就像哥伦布探索美洲一样，没有勇敢迈出第一步，也许现在“美洲”的概念会推迟不知多少年。

　　以下内容，只是一些个人看法和实现，仅供参考学习，也欢迎讨论指教。

关于DDD

　　对DDD（领域驱动设计）最初的了解，始于这一篇博文：http://www.cnblogs.com/netfocus/archive/2011/10/10/2204949.html，当时花了四五个小时阅读完，但只是初步对DDD有个了解，有点颠覆自己对编程思想的看法。2004年 Eric Evans 发表 Domain-Driven Design –Tackling Complexity in the Heart of Software （领域驱动设计- 软件核心复杂性应对之道），简称Evans DDD，这本书网上一直没有买到，很遗憾，如果有的朋友有珍藏，可以高价收购。

　　什么是DDD（领域驱动设计）？DDD中最核心的是Domain Model（领域模型），和领域模型相对的是事务脚本，领域模型和事务脚本说到底就是面向对象和面向过程的区别。

事务脚本：围绕功能，以功能为中心。将所有逻辑组织在一个单一过程，进行数据库直接调用，每笔交易（业务请求）都有自己的事务脚本，并且是一个类的公开方法。
领域模型：描述领域类，以类之间的协作完成所需功能。所谓领域模型，是一系列相互关联的对象，每个对象代表一定意义的独立体，既可以一起以一种大规模方式协作；也可以小到以单线方式运行。

　　好像有个报告统计，大约80%的程序员使用事务脚本编程，三层架构（UI、BLL、DAL）对于我们来说太熟悉了，编程的时候代码一般会集中在DAL层，致使数据访问层充斥着大量的业务逻辑，而且很难复用，每个DAL中的类就像一个单元，只为某一功能实现，也就是上面所说的“单一过程”，因为业务逻辑都实现在数据访问层了，这样业务逻辑层就成了一个空架子，有的人就会觉得BLL-业务逻辑层没有存在的必要，然后设计的时候就把业务逻辑层去掉了，就只剩UI和DAL层了，外加一些HelpClass，然后的然后。。。

　　领域驱动设计的概念从提出到现在十年了，现在很少的公司能真正的去应用，而还是采用事务脚本的方式，为什么？其实就是一种思想，或者说方式的转变，就好比你以前习惯用手直接吃饭，现在让你拿筷子吃饭，肯定会不习惯。当然还有一部分原因是领域驱动设计的推行，或者说国内有关这领域的大牛们很少，但我觉得不管怎样，这是个趋势，就像黑夜过后，一定会是清晨一样。

　　上面说到三层架构（UI、BLL、DAL），我们再看一下领域驱动设计的分层：

　　　　　　　　　　来自：dax.net

主要分为四层（表现层、应用层、领域层和基础层）：

Presentation Layer：表现层，负责显示和接受输入；
Application Layer(Service)：应用层，很薄的一层，只包含工作流控制逻辑，不包含业务逻辑；
Domain Layer(Domain)：领域层，包含整个应用的所有业务逻辑；
Infrastructure Layer：基础层，提供整个应用的基础服务；

　　领域驱动设计主张充血模型，也就是富模型的意思，大多业务逻辑都应该被放在Domain Object里面（包括持久化业务逻辑），而Service层应该是很薄的一层，仅仅封装事务和少量逻辑，不和Dao层打交道。

　　优点：

更加符合OO的原则。
Service层很薄，只充当Facade的角色，不和Dao打交道。

　　缺点：

Dao和Domain Object形成了双向依赖，复杂的双向依赖会导致很多潜在的问题。
如何划分Service层逻辑和Domain层逻辑是非常含混的，在实际项目中，由于设计和开发人员的水平差异，可能导致整个结构的混乱无序。（这个问题在项目实际运作的时候会出现，划分很重要。）
考虑到Service层的事务封装特性，Service层必须对所有的Domain Object的逻辑提供相应的事务封装方法，其结果就是Service完全重定义一遍所有的Domain Logic，非常烦琐，而且Service的事务化封装其意义就等于把OO的Domain Logic转换为过程的Service TransactionScript。该充血模型辛辛苦苦在Domain层实现的OO在Service层又变成了过程式，对于Web层程序员的角度来看，和贫血模型没有什么区别了。（和第二点类似，如何做到Application层不包含业务逻辑，协调领域层和基础层很重要。）

　　领域模型概念参照：http://www.oschina.net/question/12_21641

　　领域驱动设计系列：http://www.cnblogs.com/daxnet/archive/2010/11/02/1867392.html

前期分析

　　关于DDD（领域驱动设计）概念有一定了解后，下面开始做一个基于领域驱动设计的项目：MessageManager（短消息系统），至于为什么要拿短消息当小白鼠？是有原因的，当然随便一个业务需求也是可以的，实践是检验理论的唯一标准。

　　MessageManager（后面就这样命名）大概类似于博客园-短消息系统，用户模块暂不考虑，只考虑短消息，大致画了一张功能分析图：

　　可能当你看到这张图的第一反应是：Are you kidding me？？？对，你没看错，MessageManager功能就是这么简单，其实领域驱动设计的项目应用应该是一些包含大型业务逻辑的，这种简单的“CURD”操作很难体现出领域驱动设计的作用，但重点不是去实现，而是一个示例框架，可能设计不是很合理，但是一个完整的流程要走下来，当然领域驱动设计包含很多东西，不只是框架设计这一点，很不幸，本篇就只是讨论的这一点。

　　MessageManager数据分析图：

　　Are you kidding me again？？？对，你又没看错！！！数据库设计就这么简单，其实不应该说是数据库设计，应该是领域模型设计-数据部分，主要体现在数据库存储，主要是两个表：User（用户表）和Message（消息表），注意我在画图的时候并没有设计字段类型，只是字段名称，类型设计应该在 Infrastructure Layer（基础层）去实现，准确的来说应该是ORM，领域模型只是定义，并不包含实现，有时候我们在做设计的时候，比如ORM使用的是EntityFramework，采用的模式是：Database First，也就是dax.net所说的：

　　EntityFramework中的“从数据库生成模型”功能应该去掉，但只是相对于领域驱动设计而言，如果项目采用事务脚本，你会发现这个功能是多么的方便，凡事都有相对性。后来EntityFramework推出“Code First”模式，这种模式就符合领域驱动设计思想，MessageManager就是采用这种方式。

　　MessageManager的扩展图：

　　因为不考虑用户模块，所以用户接入暂不考虑，只扩展一个消息接口，实现方式是：ASP.NET WebAPI，采用WebAPI主要原因是支持REST（无状态），这里需要注意的是此接口虽然是服务，但是属于Presentation Layer（表现层）。关于ASP.NET WebAPI可以参考：http://www.cnblogs.com/xishuai/p/3651370.html。

　　注：以上前期分析都是按照自己理解去完成，如果严格按照领域驱动设计，应该是建模专家按照严格的流程去做分析的，而不是像我这样随便画几张图。

框架搭建

　　MessageManager主要用到概念或技术点：EntityFramework、ASP.NET MVC、ASP.NET WebAPI、AutoMapper、Nunit、Unity、Unit Of Work、Repository、Specification等等。

　　解决方案：

　　主要分为四层，可以对比上面的领域驱动设计分层图，当然复杂一点不只分为四层，但是这是最基本的，dax.net在 http://www.cnblogs.com/daxnet/archive/2011/05/10/2042095.html，一文中就增加了很多东西，示例图：

　　　　　　　　　　　　　　　　　　来自：dax.net

　　XXXX.Repositories项目dax.net在设计的时候放在了Domain中，也就是命名：XXXX.Domain.Repositories，但我觉得仓储实现应该在Infrastructure（基础层）中实现，Domain中只是定义仓储契约，也就是Infrastructure（基础层）中的MessageManager.Repositories，实现仓储的具体实现，并提供持久化操作。

　　工作流程描述可以用Unit Of Work一文中画过一张图表现：

点击查看大图

代码实现

　　MessageManager代码编写主要是四个方面：框架底层、功能实现、单元测试、前端页面。

　　框架底层实现可以结合上面那张图和源码去理解，前端页面整理放在MessageManager.WebFiles项目中，页面原始来自博客园-短消息系统，做了一点修改。这边说下单元测试，关于单元测试可以参考：http://www.cnblogs.com/xishuai/p/3728576.html，因为我开发工具使用的是VS 2012，使用的是：NUnit Test Adapter，MessageManager项目中进行单元测试最重要的是Infrastructure（基础层）和Application（应用层），Infrastructure（基础层）主要是对MessageManager.Repositories项目进行单元测试，也就是测试项目：MessageManager.Repositories.Tests，测试主要包含仓储持久化操作，如下：

　　功能实现主要是领域模型设计、仓储设计、应用层协调、表现层（MVC、WebAPI）代码编写等，当然还有一些应用程序配置，比如Automapper类型映射、Unity依赖注入配置等。说到领域模型设计，就多说一点，先了解领域模型涉及的概念：实体、值对象、聚合、聚合根。MessageManager项目包含两个实体：User实体和Message（实体），当时设计的时候，我是把User作为实体、Message作为聚合根，也就是下面代码：

/**
* author:xishaui
* address:https://www.github.com/yuezhongxin/MessageManager
**/

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace MessageManager.Domain.DomainModel
{
    public class Message : IAggregateRoot
    {
        #region 构造方法
        public Message()
        {
            this.ID = Guid.NewGuid().ToString();
        }
        #endregion
        
        #region 实体成员
        public string FromUserID { get; set; }
        public string FromUserName { get; set; }
        public string ToUserID { get; set; }
        public string ToUserName { get; set; }
        public string Title { get; set; }
        public string Content { get; set; }
        public DateTime SendTime { get; set; }
        public bool IsRead { get; set; }
        public virtual User FromUser { get; set; }
        public virtual User ToUser { get; set; }
        #endregion

        #region IEntity成员
        /// <summary>
        /// 获取或设置当前实体对象的全局唯一标识。
        /// </summary>
        public string ID { get; set; }
        #endregion
    }
}

　　Message继承IAggregateRoot，User和Message组成一个消息聚合，聚合根为Message，访问消息聚合内的成员，必须通过聚合根（Message）才能访问，但是在做的过程中，有一个需求就是要通过用户名获取User，如果通过Message访问就很不合理，因为这不包含任何的消息操作，所以后面就把User单独作为一个聚合，聚合根为其本身，这边说明的就是，聚合边界划分不一定一成不变，需要根据具体的业务场景去划分，就比如：做User模块的时候，Message就不能设计成聚合了，而应该是User。

　　还有一点就是EntityFramework使用Code First的时候，因为我们“字段”都是设计在Domain层中（并不包含配置），实现却是在Infrastructure层，如何进行数据库字段类型设计？或是表字段关联？实现主要是使用ModelConfigurations，在生成之前添加Model配置，我觉得这是EntityFramework在领域驱动设计开发中优点之一，设计和实现完全区分开，示例代码：

 1 using System.ComponentModel.DataAnnotations;
 2 using System.Data.Entity.ModelConfiguration;
 3 using MessageManager.Domain.DomainModel;
 4 
 5 namespace MessageManager.Repositories.EntityFramework.ModelConfigurations
 6 {
 7     public class MessageConfiguration : EntityTypeConfiguration<Message>
 8     {
 9         /// <summary>
10         /// Initializes a new instance of <c>MessageConfiguration</c> class.
11         /// </summary>
12         public MessageConfiguration()
13         {
14             HasKey(c => c.ID);
15             Property(c => c.ID)
16                 .IsRequired()
17                 .HasMaxLength(36)
18                 .HasDatabaseGeneratedOption(DatabaseGeneratedOption.None);
19             Property(c => c.FromUserID)
20                 .IsRequired()
21                 .HasMaxLength(36);
22             Property(c => c.ToUserID)
23                 .IsRequired()
24                 .HasMaxLength(36);
25             Property(c => c.Title)
26                 .IsRequired()
27                 .HasMaxLength(50);
28             Property(c => c.Content)
29                 .IsRequired()
30                 .HasMaxLength(2000);
31             Property(c => c.SendTime)
32                 .IsRequired();
33             Property(c => c.IsRead)
34                 .IsRequired();
35             ToTable("Messages");
36 
37             // Relationships
38             this.HasRequired(t => t.FromUser)
39                 .WithMany(t => t.SendMessages)
40                 .HasForeignKey(t => t.FromUserID)
41                 .WillCascadeOnDelete(false);
42             this.HasRequired(t => t.ToUser)
43                 .WithMany(t => t.ReceiveMessages)
44                 .HasForeignKey(t => t.ToUserID)
45                 .WillCascadeOnDelete(false);
46         }
47     }
48 }

　　上面代码中的下面部分是添加外键配置，EntityFramework中的模型-添加配置：

1         protected override void OnModelCreating(DbModelBuilder modelBuilder)
2         {
3             modelBuilder
4                 .Configurations
5                 .Add(new UserConfiguration())
6                 .Add(new MessageConfiguration());
7             base.OnModelCreating(modelBuilder);
8         }

　　下面再说下MessageManager.Application（应用层）的协调配置，先看下面的一张图，注意后面所做的操作都是领域层或是基础层去实现的，并不是应用层实现，应用层只是做协调处理，不要把应用层当做BLL（业务逻辑层）。

　　　　　　　　　　　　　　　　　　　　　　　　点击查看大图

开源-发布

GitHub 开源地址：https://github.com/yuezhongxin/MessageManager
ASP.NET MVC 发布地址：http://www.xishuaiblog.com:8081/
ASP.NET WebAPI 发布地址：http://www.xishuaiblog.com:8082/api/Message/GetMessagesBySendUser/小菜

　　注：ASP.NET WebAPI 暂只包含：获取发送放消息列表和获取接收方消息列表。

　　调用示例：

GetMessagesBySendUser（获取发送方）：http://www.xishuaiblog.com:8082/api/Message/GetMessagesBySendUser/用户名
GetMessagesByReceiveUser（获取接受方）：http://www.xishuaiblog.com:8082/api/Message/GetMessagesByReceiveUser/用户名

　　WebAPI 客户端调用可以参考 MessageManager.WebAPI.Tests 单元测试项目中的示例调用代码。

　　Web 示例页面：

撰写短消息：

发件箱：

查看/回复短消息：

　　WebAPI 示例页面：

后记

　　关于时间成本：

MessageManager项目：两天（包含晚上）+两个晚上；
本篇博客：一个下午+一个晚上（很晚）+外加更正无数；

　　关于DDD实践-MessageManager项目，有几个问题需要记录一下：

Domain Model（领域模型）：领域模型到底该怎么设计？你会看到，MessageManager项目中的User和Message领域模型是非常贫血的，没有包含任何的业务逻辑，现在网上很多关于DDD示例项目多数也存在这种情况，当然项目本身没有业务，只是简单的“CURD”操作，但是如果是一些大型项目的复杂业务逻辑，该怎么去实现？或者说，领域模型完成什么样的业务逻辑？什么才是真正的业务逻辑？这个问题很重要，后续探讨。
Application（应用层）：应用层作为协调服务层，当遇到复杂性的业务逻辑时，到底如何实现，而不使其变成BLL（业务逻辑层）？认清本质很重要，后续探讨。
。。。

　　因为时间比较紧，MessageManager 项目中很多设计或功能实现不是很合理或完善，比如：异常拦截、日志管理等都没有实现，但走出第一步，就有第二步，第三步。。。

　　如果你觉得本篇文章对你有所帮助，请点击右下部“推荐”，^_^

全站频道

大家都在搜索：