上一篇:《IDDD 实现领域驱动设计-一个简单业务用例的回顾和理解

在《实现领域驱动设计》第二章的前半部分内容中,提到领域和子域的概念,并且作者把这两者又进行了细致的区分,其实在《领域驱动设计》书中,也有进行详细说明,只不过是在第十五章《精炼》中,章节比较靠后,我先是读了《实现领域驱动设计》这部分的内容,但读完之后,完全没有任何的感觉,或者说我自己和作者没有产生一些共鸣,也记不起来自己到底读了什么内容,但是在读《领域驱动设计》对应这部分内容的时候,我觉得有些内容是我想要的,也产生了一些共鸣,这让我对之前短消息项目也有了一些新的思考,我觉得还是蛮有价值的,下面是自己的一些理解。


一张很重要的图,引自:《实现领域驱动设计》

Domain 领域

首先,领域(Domain)不是领域模型(Domain Model),不要把他们两个画等号,从字面上进行理解,“领”的意思,可以理解为领土、领地或属于的某一区域,但不管它包含的是什么,它总是有一个界限,也就是说这个界限要进行明确,如果不进行明确,就会产生一些麻烦,比如“领地纠纷”等等,这个界限其实就可以看作是“领”的意思,“域”的意思,就是一个方面的具体称谓,加上“领”,领域的意思,其实就是明确某一方面的称谓。可能有点晕,我们开发某一套业务系统,比如快递行业的业务系统,那么这个快递业务系统之内的所有业务都包含在领域中,这个领域称之为快递业务领域,其中可能有很多的子领域,或者是业务模块,但都属于这个领域之内,如果超出这个领域之外,那么业务模块将不包含在快递业务领域之内了。在上一篇中有说到领域专家,其实,就是对某一领域精通的人,关键词是某一领域,而不是所有领域,强调的是界限的重要性。

从上面图中可以看出,业务领域中所有东西构成了这个业务的领域概念,也就是说它是唯一的,你开发什么业务系统,首先需要明确的是,你业务系统的领域是什么?如果连这个都确定不了,那么领域驱动设计也就没有再进行下去的必要了。让我自己来考验自己一下,之前开发的消息项目(MessageManager),这个消息项目的领域是什么?我想你应该会和我一样,脑海中首先想到的应该就是消息领域(Message Domain),其实我觉得这个答案没什么问题,消息项目不围绕消息领域开展,那围绕什么开展呢,你可能会有一些疑问,比如消息项目中会有一些用户模块,用户模块不应该属于用户领域吗?如果消息项目只有一个消息领域,那它们俩不相违背吗?其实这个答案,可以从上面的图中找到,消息领域是一个大的概念,它包含了这个消息项目中所有的业务领域概念,消息项目中的用户模块,只不过是消息领域的内部的一部分而已,不要被消息领域中的“消息”字眼所迷惑。

对于开发者来说,理解领域的概念是有一些歧异的,比如消息领域,我们开发者该怎么去描述它,或者表达它呢?我想你应该和我一样,首先,新建一个 Message.Domain 类库项目,然后把所有的业务操作都在这个类库中进行实现,实现完成之后,你告诉领域专家,说这个 Message.Domain 项目就是消息领域,仔细一想,好像也确实有些道理,对于开发者来说,消息领域的表达就是项目代码的实现,这样做也无可厚非。但是,有一点非常重要,在消息领域确定的过程中,不是只有开发人员的参与,最重要的还要有领域专家的参与和讨论,其实,对消息领域的最理解的人,不是开发者自己,而是领域专家,消息领域的表达也不只是代码表现这么简单,而是之前提到的通用语言,消息领域在开发者和领域专家之间的传递和确定,这个介质其实就是通用语言,之前有说到通用语言是开发者和领域专家共同创建的,它的表现形式可以是一个白板,也可以是一堆文件,又或者是一个项目代码等等,但不论是什么东西,它能在开发者和领域专家正确传递领域所包含的业务概念即可。

在上面图中,领域中有一个核心域(Core Domain)的概念,核心域是什么?它是领域中最重要的一块,你可以把它看作是人体中的心脏,也就是说是最核心的东西,开发者和领域专家花费最多的精力都是在它上面,一个业务系统一般有且只有一个核心域,但是一般核心域的精炼工作是需要花费很多的时间和精力,而且也很容易出错,如果业务系统中核心域的精炼出现了问题,那么这个业务系统注定是失败的,因为当一个核心域确定下来之后,开发者和领域专家剩余的工作,都是围绕着核心域进行展开的,比如一个人得了心脏病,而医生在诊断的时候,却认为是肝脏出了问题,然后他就对这个病人的肝脏做了手术,可想而知后果会怎样。。。这个看似简单的问题,但其实中间也蕴含了一些重要东西,首先,我们可以把它抽离出来,有三个人物:病人、诊断医生和手术医生,再想一下,我们业务系统开发,也有三个重要对象:业务系统、领域专家和开发者,然后,你再对它们进行对比下,就可以得出一些东西了,诊断医生是最了解病人的,由他来确定病人得了什么病,就好比领域专家把业务系统的核心域精炼出来,手术医生只不是实施者,用的是手术刀,而开发者用的是代码,但和看病不一样的是,核心域的精炼是领域专家和开发者共同探讨决定的,这就避免了诊断医生和手术医生所产生一些不必要的“冲突”,说了这么多,总而言之,核心域的精炼很重要,需要领域专家和开发者共同参与。

回到我们的消息领域上,那在消息领域中,核心域是什么呢?我的个人想法是发消息业务操作,这是消息领域中最重要的一个业务操作,消息的存在就是为了传递信息,在现实生活中,对于消息相类似的就是寄信,对于写信的我来说,我其实就是寄信的领域专家,为什么?因为我自己就是用户,对于寄信用户来说,我写信的目的就是让收件人可以收到我的信,具体这封信是怎么寄出去的,公路、铁路、飞机等等,这些我都不关心,我只关心的是现在这封信有没有到收件人手里。按照这个思路进行理解,对于消息领域来说,领域专家所能描述出来的核心域描述就是:发消息,这个和之前我们提到的待定项提交到冲刺一样,最简单的业务描述就是这样,至于消息发送限制、或者发送之后要不要邮件通知,这都是发消息具体的内部实现,对于消息领域以后的业务变化来说,变的也只是核心域的内部而已,我们只需要改变具体的实现就可以了,有点以不变应万变的意思,不变的是核心域,变的是核心域的内部实现。

描述这么多,可能有点晕,只需要记住两个概念就可以了,领域和核心域,具体的深入理解,只有运用后才可以真正体会到。

SubDomain 子域

什么是子域(SubDomain)呢?理解子域的概念,必须和核心域对应起来,子域也是领域的一部分,只不过它的重要性没有核心域那么大,它们之间的关系,你可以看作是人体器官中,心脏和其他器官的关系,在《领域驱动设计》中,其实并没有子域的概念,而是通用子域(Common Subdomain),而在《实现领域驱动设计》中,作者把子域拆分成了支撑子域(Generic Subdomain)和通用子域(Common Subdomain)。对于领域来说,除了核心域,用来支撑核心域的子域,就可以称之为支撑子域,在整个领域中,可以被公用的子域,称之为通用子域,通用子域还有一个理解是,在某一个业务领域中,它可能是被看作是通用领域,但是在另外一个业务领域中,它可能就被看作是核心域了,举个例子,比如在团购业务系统中,地图服务可能就被看作是通用领域,而对于地图服务商来说,毫无疑问,地图服务将是他们的核心域。

这些概念性的东西可能理解起来很费劲,我们再回到消息领域中,在上面分析中,我们已经确定了“发消息”是核心域,插一句,有人说,那回复消息是什么啊?难道有两个核心域?其实发消息就包含回复消息,因为回复消息也是发消息的一种信息,回到正题上,我们在消息领域中精炼一下支撑子域和通用子域,我现在可以想到的就是消息验证服务领域,就是在发消息之前对发件人、收件人、以及对消息内容进行验证,就好比你去邮局寄一封信,工作人员需要验证一下收发件地址一样,消息验证服务领域用来支撑发消息核心域,所以可以把它单独精炼出来进行探讨,还有就是,对于支撑子域来说,在整个领域中,可能会有多个,但大部分都是围绕核心域进行展开的,这也就是“支撑”的具体含义吧,说到这,我现在脑子里面有闪现一个,那就是消息发送之后的通知服务,这个也可以看作是支撑子域,需要记住的是,支撑子域虽然没有核心域那么重要,但它也是领域的一种,也是非常重要的,不要完全忽略它。

说了支撑子域,再来分析一下,消息领域中的通用子域,其实就是用户领域,用户的概念会贯穿整个消息领域,因为一切都是用户进行操作完成相关业务,用户领域的概念其实和上面说到的地图服务领域是一样的,在用户业务系统中,用户领域就不是通用子域了,而是核心域,对于非用户业务系统来说,用户领域在其他业务系统中,都可以被看作是通用子域。可能还有一点内容容易造成误解,就是消息领域中,“用户”的概念是很重要的,发消息是用户进行发送,那用户领域是不是应该被看作是核心域呢?我记得当时在开发消息项目的时候,曾经就把发消息业务操作放在了用户模型中,认为用户才能发消息啊,那如果是这样的理解思路,所有的业务系统中的业务操作,都应该是放在用户模型中,因为只有用户才能进行这些操作,但好像并不是这么回事,我们有点过于“面向对象”了,应用软件中和现实生活中的用户概念是不太一样的。

在业务领域中,对于通用子域来说,是比较容易精炼的,但是对于支撑子域来说,精炼它是有些难度的,难点就在于它和核心域的区分,有时候,我们可能会从核心域中剥离支撑子域,当然,最重要的,还是领域专家和开发者之间如何确立通用语言并与之沟通。


啰里八嗦的,就记录到这!

IDDD 实现领域驱动设计-理解领域和子域的更多相关文章

  1. 领域驱动设计理解&总结

    领域驱动设计理解&总结 这篇文章主要是通读<实现领域驱动设计>之后自己的理解和总结(同时也参照一些博文的分析来加深自己的理解): 有些疑问是自定义内容,虽然有自己的理解,但依然感觉 ...

  2. DDD领域驱动设计之领域服务

    1.DDD领域驱动设计实践篇之如何提取模型 2.DDD领域驱动设计之聚合.实体.值对象 3.DDD领域驱动设计之领域基础设施层 什么是领域服务,DDD书中是说,有些类或者方法,放实体A也不好,放实体B ...

  3. 基于ABP落地领域驱动设计-04.领域服务和应用服务的最佳实践和原则

    目录 系列文章 领域服务 应用服务 学习帮助 系列文章 基于ABP落地领域驱动设计-00.目录和前言 基于ABP落地领域驱动设计-01.全景图 基于ABP落地领域驱动设计-02.聚合和聚合根的最佳实践 ...

  4. DDD领域驱动设计之领域基础设施层

    1.DDD领域驱动设计实践篇之如何提取模型 2.DDD领域驱动设计之聚合.实体.值对象 其实这里说的基础设施层只是领域层的一些接口和基类而已,没有其他的如日子工具等代码,仅仅是为了说明领域层的一些基础 ...

  5. DDD领域驱动设计:领域事件

    1 前置阅读 在阅读本文章之前,你可以先阅读: DDD领域驱动设计是什么 DDD领域驱动设计:实体.值对象.聚合根 DDD领域驱动设计:仓储 MediatR一个优秀的.NET中介者框架 2 什么是领域 ...

  6. [.NET领域驱动设计实战系列]专题十一:.NET 领域驱动设计实战系列总结

    一.引用 其实在去年本人已经看过很多关于领域驱动设计的书籍了,包括Microsoft .NET企业级应用框架设计.领域驱动设计C# 2008实现.领域驱动设计:软件核心复杂性应对之道.实现领域驱动设计 ...

  7. NET 领域驱动设计实战系列总结

    NET 领域驱动设计实战系列总结 一.引用 其实在去年本人已经看过很多关于领域驱动设计的书籍了,包括Microsoft .NET企业级应用框架设计.领域驱动设计C# 2008实现.领域驱动设计:软件核 ...

  8. 解构领域驱动设计(一):为什么DDD能够解决软件复杂性

    1 为什么我要研究领域驱动设计 1.1 设计方法各样且代码无法反映设计 我大概从2017年10月份开始研究DDD,当时在一家物流信息化的公司任职架构师,研究DDD的初衷在于为团队寻找一种软件设计的方法 ...

  9. 如何使用ABP进行软件开发(2) 领域驱动设计和三层架构的对比

    简述 上一篇简述了ABP框架中的一些基础理论,包括ABP前后端项目的分层结构,以及后端项目中涉及到的知识点,例如DTO,应用服务层,整洁架构,领域对象(如实体,聚合,值对象)等. 笔者也曾经提到,AB ...

  10. 基于ABP落地领域驱动设计-01.全景图

    什么是领域驱动设计? 领域驱动设计(简称:DDD)是一种针对复杂需求的软件开发方法.将软件实现与不断发展的模型联系起来,专注于核心领域逻辑,而不是基础设施细节.DDD适用于复杂领域和大规模应用,而不是 ...

随机推荐

  1. DDD CQRS架构和传统架构的优缺点比较

    明天就是大年三十了,今天在家有空,想集中整理一下CQRS架构的特点以及相比传统架构的优缺点分析.先提前祝大家猴年新春快乐.万事如意.身体健康! 最近几年,在DDD的领域,我们经常会看到CQRS架构的概 ...

  2. ExtJS 4.2 业务开发(三)数据添加和修改

    接上面的船舶管理业务,这里介绍添加和修改操作. 目录 1. 添加操作 2. 修改操作 3. 在线演示 1. 添加操作 1.1 创建AddShipWindow.js 在业务中的view目录下创建一个Ad ...

  3. ASP.NET MVC with Entity Framework and CSS一书翻译系列文章之目录导航

    ASP.NET MVC with Entity Framework and CSS是2016年出版的一本比较新的.关于ASP.NET MVC.EF以及CSS技术的图书,我将尝试着翻译本书以供日后查阅. ...

  4. [C#] string 与 String,大 S 与小 S 之间没有什么不可言说的秘密

    string 与 String,大 S 与小 S 之间没有什么不可言说的秘密 目录 小写 string 与大写 String 声明与初始化 string string 的不可变性 正则 string ...

  5. 操作系统篇-hello world(免系统运行程序)

     || 版权声明:本文为博主原创文章,未经博主允许不得转载. 一.前言     今天起开始分享关于操作系统的相关知识,本人也是菜鸟一个,正处于学习阶段,这整个操作系统篇也是我边学习边总结的一些结果,希 ...

  6. AFNetworking 3.0 源码解读(九)之 AFNetworkActivityIndicatorManager

    让我们的APP像艺术品一样优雅,开发工程师更像是一名匠人,不仅需要精湛的技艺,而且要有一颗匠心. 前言 AFNetworkActivityIndicatorManager 是对状态栏中网络激活那个小控 ...

  7. await and async

    Most people have already heard about the new “async” and “await” functionality coming in Visual Stud ...

  8. ASP.NET Core 中文文档 第四章 MVC(4.5)测试控制器逻辑

    原文: Testing Controller Logic 作者: Steve Smith 翻译: 姚阿勇(Dr.Yao) 校对: 高嵩(Jack) ASP.NET MVC 应用程序的控制器应当小巧并专 ...

  9. 子类继承父类时JVM报出Error:Implicit super constructor People() is undefined for default constructor. Must define an explicit constructor

    当子类继承父类的时候,若父类没有定义带参的构造方法,则子类可以继承父类的默认构造方法 当父类中定义了带参的构造方法,子类必须显式的调用父类的构造方法 若此时,子类还想调用父类的默认构造方法,必须在父类 ...

  10. 【干货分享】流程DEMO-合同会审表

    流程名: 合同会审表  业务描述: 合同的审批及签订  流程相关文件: 流程包.xml 事务呈批表业务服务.xml 事务呈批表主数据.xml  流程说明: 1.此流程必须先进行事务呈批表流程的配置才可 ...