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

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

引子

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

  • [.NET领域驱动设计实战系列]专题二:结合领域驱动设计的面向服务架构来搭建网上书店 
  • 领域驱动设计实践
  • 领域驱动设计系列文章汇总

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

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

    所谓的战略建模有两点:界限上下文(Bounded Context)、上下文映射图(Context Mapping)。

    来看一下它们的定义:

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

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

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

  1. 首先介绍他的例子:一个简易的销售系统;
  2. 给出UML实体框图;
  3. 然后突突的给出一堆代码;

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

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

    它直接让我们这些技术狂热爱好者们瞬间偏离了DDD以业务为核心,不依赖具体技术实现的初衷。DDD本来就是引导我们来解决业务上的问题,而不是来让我们炫耀新技能的。如果只是介绍EF,那这篇文章是篇合格的文章。但,如果把它作为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,强烈建议学习netfocusENode框架!

13楼netfocus
划分领域、设计好bc,也许不难;而写代码时,我们有时经常会被技术性的东西带进去,偏离ddd以业务为中心的出发点。所以,我们写任何一个类,方法,属性时,都要想想这个类的代表的是什么概念,什么含义,是否在当前的bc下是合理的,是否有歧义等问题。
12楼统一脑残
好文要顶要赞也要推荐,虽然现在不懂,先mark一下以备有用#128512;
11楼玻璃鱼儿
很难得的好文,终于听到了不同的声音。
10楼HackerVirus
@李玉宝,学习了!
9楼程序诗人
mark 学习
8楼刺激雄
对博主的体会感同身受,一直想搭建自己的领域驱动模型,试了两次发现成果是相当于在自己之前的框架上加入DTO和依赖注入,对大神们的文章只有膜拜,感觉看懂了,但是做不出来(可能是水平所限吧),对博主这种谈论自己观点的文章,从学习习惯上非常能接受,已关注,希望博主多写一些这样的文章。
Re: 李玉宝
@AllEmpty,@netfocus,@田园里的蟋蟀,,感谢三位大神的支持,一直在追赶你们的脚步!,,@刺激雄,一起学习
7楼HK_killer
从您这个博文里面的图 来看 好像是一个模块算是一个子域,那么请教下 是不是一般的项目如果要划分子域的话 是不是也应该按照模块来划分?还是因项目而异呢?
Re: 李玉宝
@HK_killer,划分子域主要是业务上的划分,不过对于国内需求不明,业务不明,造成划分起来比较麻烦。,而且划分合理的子域应该对应一个限界上下文,从而对应一个解决方案,而不仅仅是一个模块(当然我们实现的小项目可以用模块的形式)。,比如支付子域,应该单独一个解决方案,然后用服务(如WSDL/REST)的方式提供给销售用,这样做的好处...额,丫做大了,可以单独上市,哈哈
6楼HK_killer
@李玉宝,,受教了
5楼挨踢男.Orz
mark 赞
4楼Hetring
感谢分享。。
3楼田园里的蟋蟀
赞!
2楼~Js
看了文章前2段,我就决定点赞了。,,因为一些想法给我一样, 现在网上很多人说ddd。 ,,但是一般都是搬来一丢新名词, 新技术,什么cqrs, event...,,然后再自己搞个框架现实了自己的那一套想法, 说着是ddd框架。,,我真的醉了,ddd是领域驱动设计。 重要的是领域设计。 ,,而不是那些什么新名词!
Re: 李玉宝
@~Js,呵呵,同感,不过那些代码写的真心可以,哈哈!
1楼AllEmpty
没抢到沙发...,受教了,谢谢楼主的分享

相关内容推荐