当前位置 : 主页 > 编程语言 > 其它开发 >

领域驱动设计实战

来源:互联网 收集:自由互联 发布时间:2022-05-25
引子 自从去年接触 DDD 以来,阅读了大量的相关书籍,看了园子里面很多 DDD 方面的文章,也在实际项目中也有意无意的使用 DDD 的一些思想和方法。但总觉得这些知识太分散,没有给自
引子

  自从去年接触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设计之道

  就像前面说的,我们进行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,强烈建议学习netfocusENode框架!

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

上一篇:难免的尴尬:代码依赖
下一篇:没有了
网友评论