领域驱动开发实战----战略建模

引子

自从去年接触DDD以来，阅读了大量的相关书籍，看了园子里面很多DDD方面的文章，也在实际项目中也有意无意的使用DDD的一些思想和方法。但总觉得这些知识太分散，没有给自己思想带来质的升华。观摩了园子里面很多DDD的例子：

等等还有很多，这些例子的质量都很高，图文并茂，一堆让人流口水的代码示例。但每次看完例子后，我的迷茫就会又加深一分。因为我觉得很多博文都只是打着DDD的幌子，还是按自己的原来理解方式写代码而已。并没有给大家深入剖析DDD。别忘了，DDD是领域驱动设计，而不是领域驱动开发。在完成这些例子过程中，太重视出成果，出一个实际的代码项目，而忽视了设计，即使有些设计，也只是停留在战术建模的阶段，并没有站在战略建模的高度来对需求进行分析，通常给出一个UML类关系图，一个分层架构图就开始突突突地来一堆代码，最后还不忘贴两个漂亮的UI截图，引起无数粉丝追捧（额～～他们的粉丝中也有我，看来可以把我拉黑了）。用沃恩.弗农大神的话，这样做只能算DDD-Lite，离真正的DDD还有段距离。

于是我有了写这篇文章的想法。

所谓的战略建模有两点：界限上下文（Bounded Context）、上下文映射图（Context Mapping）。

来看一下它们的定义：

限界上下文：它是一个限定边界的环境，在该环境中，每一个模型的概念（包括它的属性和操作）都具有特殊的含义。它是战略建模的核心。

上下文映射图：通用使用框图或代码的方式来展现限界上下文之间的集成关系。

它们为什么重要，我以dax.net大大的一个例子来说明，来看一下他的一篇文章EntityFramework之领域驱动设计实践（三），文中内容大概是这样安排的：

首先介绍他的例子：一个简易的销售系统；
给出UML实体框图；
然后突突的给出一堆代码；

这是一个典型的战术建模的例子。而且该文中有一句极其误导DDD新人的话，我不得不吐槽一下：

上面的模型表述了领域模型中各个实体及其之间的关系。我们先不去讨论整个系统的业务会是什么样的，我们先看看EF是如何支持实体和值对象概念的。

它直接让我们这些技术狂热爱好者们瞬间偏离了DDD以业务为核心，不依赖具体技术实现的初衷。DDD本来就是引导我们来解决业务上的问题，而不是来让我们炫耀新技能的。如果只是介绍EF，那这篇文章是篇合格的文章。但，如果把它作为DDD的文章，那它就是个反面教程。

很不幸，本文开始的几个链接也都被我划到反面教程之列，而且类似的文章园子里面还有很多。这些文章用来教大家写代码可以，但不能作为DDD的教程。

我的DDD设计之道

就像前面说的，我们进行DDD的第一步，不应该是急着去创建实体模型，而应该站在更高的层面去理解需求，划分领域。这里我就以dax.net这个简易的销售系统为例。首先我们来看看那篇文章中的模型图（注意：这里不是用这个模型图，而仅仅是参考一下用来分析业务，就当这个模型图是会说话的客户吧！）：

必须坐下来和客户（就是上面这个模型图）好好谈谈了，以下为谈话内容：

把对话内容总结一下，我们可以看出需求业务大概是这样的：

客户可以在本系统进行支付，并且可以使用多信用卡支付；
为客户生成订单；
在现有的订单基础上可以进行退订；
管理客户信息，主要是信用卡信息管理；
管理产品信息；
管理产品分类信息；

来把这几条业务进行划分，得到原始领域结构图：

上图只是对领域进行了划分及确定限界上下文，各限界上下文的关系下面会有介绍。这里共4个限界上下文：客户上下文，订单上下文，支付上下文及产品上下文。这里有以下几点要特别说明：

通过对领域的划分，优化了原有系统设计中Item实体即表示订单项目，又表示产品的混淆的定义。在订单上下文中，没有产品这个概念，只有订单项，订单项的属性数据（主要是产品名称，单价）会在生成订单项实体时从产品上下文中的产品获取；
支付上下文中没有"客户"这个概念，只有"帐户"这个概念(图中画成帐号，在此纠正一下)，同订单中的订单项，"帐户"的属性也会在生成帐户实体时从其他上下文中获取，这里是从客户上下文中获取，"帐户"是客户的一个子集；
随着业务的增长，可以把退订业务从订单管理子域中划分出来，作为一个单独子域，这里暂时先不考虑；

可以看出，在确定子域及限界上下文后，一些容易混淆的概念会逐渐得到清晰的描述，这样可以方便开发团队、业务人员及客户之间的交流，而且还为我们开发时划分项目功能提供最直接的依据。

我们进一步对该图进行优化。来看一下限界上下文之间的关系，即上下文映射图：

图中的实线连接，表示两端的限界上下文之间存在联系。线上标注的U/D表示上游/下游。通常情况下：上游的限界上下文会为下游提供访问接口（或服务），下游使用一个防腐层获取从上游接口传过来的数据，然后转化成本限界中使用的实体。

举个例子：产品上下文是订单上下文的上游。当用户进行产品选购时，会向订单里面添加订单项（丫的，这里没设计购物车～～）：

    class Order    {        private IList<Item> _items = new List<Item>();         //支付上下文中的防腐层        private IACLService _iaclService;        public Order(IACLService aclService)        {            _iaclService = aclService;        }        /// <summary>        /// 添加订单项        /// </summary>        /// <param name="productid">产品ID</param>        /// <param name="count">产品个数</param>        public void AddItem(string productid, int count)        {            Item item = _iaclService.GetItemFor(productid);            item.Count = count;            _items.Add(item);        }    }

在伪实现中，添加订单项的函数AddItem参数用的是产品的id，而不是产品的具体信息，这样就可以实现订单项与产品的解耦。假设我们的产品管理子域是通过WCF用服务的方式实现，防腐层就可以通过访问服务来获取该产品，然后把它转化成一个Item。从而实现订单项的添加。

DDD方面的代码实现会在近期放出，敬请期待！

后记

本文是站在个人理解角度去阐述DDD，在实现过程中也没有涉及CQRS/AES等概念，只是想说明一下，如果使用DDD，请站在业务的角度，而不是技术的角度。

关于学习DDD，强烈建议学习netfocus的ENode框架！

本文如有冒犯之处还请海涵，欢迎拍砖，不过你要是进行人身攻击，我也只能在心里画个圈圈诅咒你一下。

13楼netfocus: 划分领域、设计好bc，也许不难；而写代码时，我们有时经常会被技术性的东西带进去，偏离ddd以业务为中心的出发点。所以，我们写任何一个类，方法，属性时，都要想想这个类的代表的是什么概念，什么含义，是否在当前的bc下是合理的，是否有歧义等问题。

12楼统一脑残: 好文要顶要赞也要推荐，虽然现在不懂，先mark一下以备有用#128512;

11楼玻璃鱼儿: 很难得的好文，终于听到了不同的声音。

10楼HackerVirus: @李玉宝，学习了！

9楼程序诗人: mark 学习

8楼刺激雄: 对博主的体会感同身受，一直想搭建自己的领域驱动模型，试了两次发现成果是相当于在自己之前的框架上加入DTO和依赖注入，对大神们的文章只有膜拜，感觉看懂了，但是做不出来（可能是水平所限吧），对博主这种谈论自己观点的文章，从学习习惯上非常能接受，已关注，希望博主多写一些这样的文章。

7楼HK_killer: 从您这个博文里面的图来看好像是一个模块算是一个子域，那么请教下是不是一般的项目如果要划分子域的话是不是也应该按照模块来划分？还是因项目而异呢？

6楼HK_killer: @李玉宝，，受教了

5楼挨踢男.Orz: mark 赞

4楼Hetring: 感谢分享。。

3楼田园里的蟋蟀: 赞！

2楼~Js: 看了文章前2段，我就决定点赞了。，，因为一些想法给我一样，现在网上很多人说ddd。，，但是一般都是搬来一丢新名词，新技术，什么cqrs, event...，，然后再自己搞个框架现实了自己的那一套想法，说着是ddd框架。，，我真的醉了，ddd是领域驱动设计。重要的是领域设计。，，而不是那些什么新名词！

1楼AllEmpty: 没抢到沙发...，受教了，谢谢楼主的分享