由参加领域驱动设计大会与自己所想的

2017首届领域驱动技术大会一直是我非常期望的,要非常感谢右军赠送的门票能够让我领略大会风采。

这届大会组织者非常用心,组织了非常多的话题可供探讨,确实大会的内容给我带来的感觉是震撼的,我之前对领域的了解也仅从《领域驱动设计》以及《实现领域驱动设计》这两本书中有过学习,以及在实现微服务生态体系的过程中有过一些接触。

在大会的整个进程中,听了很多老师不同主题的演讲,让我印象极为深刻的还是:张逸老师的《Bounded Context的实践意义》、腾云老师的《DDD-没那么难》。下面我将分别结合这二个议题谈谈我自己的一些想法。

Bounded Context(限界上下文)的实践意义


(因为光线和距离的原因照片可能不清晰,望大家见谅)

首先我们先来解释一下,什么是限界上下文。

《实现领域驱动设计》这本书中解释到:限界上下文是一个显式边界,领域模型便存在于边界之内。在边界内,通用语言中的所有术语和词组都有特定的含义,而模型需要准确地反映通用语言。

用一段更形象的语言来描述:我们每天都去上班,上班的时候会换乘地铁,我从8号线下车,换乘2号线,然后再去换乘10号线,这样最终到达某一个地点,结束上班这个过程。在这个过程中,8号线、2号线和10号线都可以理解为不同的限界上下文,我们中间换乘的动作可以理解为领域事件,而我们最终的目标是为了上班,这个就是关键事件,我们上班就是在不同的上下文中切换。

我们还可以把上下文理解为一个模块,一个系统、一个应用或者一个服务。在我看来,限界上下文的存在对微服务的划分是有重大意义的,但是限界上下文不是新的概念,早在SOA时代就已经存在,只是当时在企业应用的时候并没有将SOA和DDD过多的联系在一起,不知道还有多少同学知道板桥里人(彭晨阳)的,早在2008年的时候在他的json网站中就已经对SOA和DDD的关系做过一些解释:

SOA服务是在松耦合组件分离后的再次打包,而Evans DDD则是一把切断组件关系的利刃。从这个方面看,DDD应该是更基础平台,万丈高楼平地起啊,而DDD是对象方法论集大成,集合分析模式和设计模式

通过当时的文章和解释我们不难看出实际上在SOA中更多的是使用DDD的OO来取代数据库分析设计,SOA是粗粒度的服务化打包,而DDD则是一把斩断粗粒度的利刃。正如这次大会张逸老师一句玩笑的话所说,正因为微服务拯救了DDD,通过这句话可以看出微服务的提出是真正的将DDD给与结合在了一起,而微服务的细粒度的服务与DDD本身的理念也是契合,从而达到了互相发展的境界。

张逸老师在这次演讲中深入探讨了几个关键词:康威定律,逻辑边界和物理边界,切断数据库的耦合、识别上下文的方法等等,能够明显的感觉出来,DDD也在发展也在和微服务和互联网领域不断的演进。

DDD-没那么难

腾云老师的分享更多是在实践过程中的总结,首先谈了数据驱动与领域驱动的不同点,表格如下:

我记得在2010年以前,研发人员和产品聊完需求后第一步就是要使用PowerDesigner画数据库表结构图,根据数据库表结构图倒推项目架构,后面DDD开始推广以来,慢慢的由UML图开始逐渐占用主导地位,现在表结构图已经成为架构设计的补充。

在DDD中常见二种设计模型,分别是贫血模型和充血模型。

  • 贫血模型

贫血模型是指领域对象里只有get和set方法,仅包含状态(属性),不包含行为(方法),采用这种设计时,需要分离出DB层,专门用于数据库操作。

从图中可以看出领域层的职责很弱,领域对象只是用来充当数据存储的对象。

但是这种模型整体架构清晰,自上而下单向连接。

远程访问接口 -> Facade接口 -> Service服务 -> 领域层 -> DAO -> 数据库

  • 充血模型

充血模型是贫血模型的相对定义,在这个模型中领域层的作用较大,不再是get和set方法的集合,而是将部分业务逻辑以及持久化的操作集成在内,如下图所示:

这种模型的调用关系则变成了:

应用层 -> Facade接口 -> 领域层 -> 基础设施层

其实这样的好处就是与领域对象相当的业务逻辑封装在对象内部,biz或者service层只需要调用对象进行简单的业务组装即可,不像贫血模型那样所有业务都集中在biz层或者service层中造成非常沉重难以拆分,但充血模型比较难以设计,需要有一定经验的设计师前期规划好,后期工作才能事半功倍,不然则会造成项目混乱。

在分享中腾云老师还做了实体和值对象的讲解,下面我将这二者的区别以表格的方式列出来供参考:

看到这里让我突然想起一个故事来:

有一对双胞胎,他们出生的时候,长得一模一样,以至于爸妈都分不清,不得已他们在双胞胎的脖子上系个项链来标记:谁是老大?谁是老二?其实这个“标记”就可以看作是实体的标识,只不过是用项链来标识的。

有一天小镇要统计双胞胎的分布情况,然后调查人员来到他们家,问他们爸妈:“你们家里有没有双胞胎?几对双胞胎?龙凤胎?还是。。。”,然后他们爸妈就报上:“一对双胞胎-两个小子”,然后调查人员就做了笔记走了。在这个过程中,他们丝毫没有提及双胞胎脖子上的“项链”。

这也就是实体和值对象的根本区别:实体不仅需要知道它是什么?而且还需要知道它是哪个?而值对象只需要知道它是什么就可以了。

小结

夜已深,文章写到这里,我想也应该可以结束了,大会的内容非常丰富,在这里只是把我看到的、听到的,结合我自己的一些想法看法总结出来,文章难免有些地方比较偏面还望大家海涵。

原文发布时间为:2017-12-13

本文作者:小程故事多@简书

时间: 2024-10-25 03:34:52

由参加领域驱动设计大会与自己所想的的相关文章

领域驱动设计的编码: 数据聚焦型开发的技巧

今年,Eric Evans 具有开创性的软件设计图书"Domain-Driven Design: Tackling Complexity in the Heart of Software"(领域驱动设计:软件核心复杂性应对之道) (Addison-Wesley Professional,2003 年,amzn.to/ffL1k)迎来了其出版十周年的纪念日.Evans 在本书中分享了其指导大型企业完成构建软件的过程的多年经验.他随后花了更长时间考虑 如何概括帮助这些项目获得成功的模式 -

状态模式在领域驱动设计中的使用

原文链接  作者: Tomasz Nurkiewicz  译者:陈振阳 领域驱动设计是软件开发的一种方式,问题复杂的地方通过将具体实现和一个不断改进的核心业务概念的模型连接解决.这个概念是Eric Evans提出的,http://www.domaindrivendesign.org/这个网站来促进领域驱动设计的使用.关于领域驱动设计的定义,http://dddcommunity.org/resources/ddd_terms/,这个网站有很多的描述,DDD是一种软件开发的方式: 对于大多数的软件

.NET领域驱动设计—实践(穿过迷雾走向光明)

阅读目录 开篇介绍 1.1示例介绍 (OnlineExamination在线考试系统介绍) 1.2分析.建模 (对真实业务进行分析.模型化) 1.2.1 用例分析 (提取系统的所有功能需求) 1.3系统设计.建模 (技术化业务模型) 1.3.1 枚举类型的使用 (别让枚举类型成为数值型对象) 1.3.2 基础数据.业务数据 (显示实体和隐式过程) 1.3.3 模型在数据库中的主外键关联问题 (面向对象模型与关系模型的天然抗阻) 1.3.4 角色.类型 (区分类型与面向对象概念) 1.3.5 名词

DDD领域驱动设计:聚合、实体、值对象

关于具体需求,请看前面的博文:DDD领域驱动设计实践篇之如何提取模型,下面是具体的实体.聚合.值对象的代码,不想多说什么是实体.聚合等概念,相信理论的东西大家已经知晓了.本人对DDD表示好奇,没有在真正项目实践过,甚至也没有看过真正的DDD实践的项目源码,处于极度纠结状态,甚至无法自拔,所以告诫DDD爱好者们,如果要在项目里面实践DDD,除非你对实体建模和领域职责非常了解(很多时候会纠结一些逻辑放哪里好,属于设计问题)以及你的团队水平都比较高认同DDD,否则请慎重...勿喷! 代码在后,请先看D

如何实现领域驱动设计

从Eric Evans写下经典名著Domain-Driven Design: Tackling Complexity in the Heart of Software至今,DDD刚好发展了十年的时间.它几乎成了开发复杂软件系统主要的领域设计方法,既是面向对象(组件)设计的补充,又超越了面向对象(组件)设计.DDD中提出的诸多概念如实体.值对象.聚合等,已经成为了耳熟能详的设计术语.DDD社区的发展也如火如荼,似乎并没有被层出不穷的设计思想所取代,相反,它仍在强劲地发展,吸收了许多新的概念与方法,

领域驱动设计的实现之路

2004年,当Eric Evans的那本<领域驱动设计--软件核心复杂性应对之道>(后文简称<领域驱动设计>)出版时,我还在念高中,接触到领域驱动设计(DDD)已经是8年后的事情了.那时,我正打算在软件开发之路上更进一步,经同事介绍,我开始接触DDD. 我想,多数有经验的程序开发者都应该听说过DDD,并且尝试过将其应用在自己的项目中.不知你是否遇到过这样的场景:你创建了一个资源库(Repository),但一段时间之后发现这个资源库和传统的DAO越来越像了,你开始反思自己的实现方式

领域驱动设计和开发实战

背景 领域驱动设计(DDD)的中心内容是如何将业务领域概念映射到软件工件中.大部分关于此主题的著作 和文章都以Eric Evans的书<领域驱动设计>为基础,主要从概念和设计的角度探讨领域建模和设计情况 .这些著作讨论实体.值对象.服务等DDD的主要内容,或者谈论通用语言.界定的上下文(Bounded Context)和防护层(Anti-Corruption Layer)这些的概念. 本文旨在从实践的角度探讨领域建模和设计,涉及如何着手处理领域模型并实际地实现它.我们将着 眼于技术主管和架构师

EntityFramework之领域驱动设计实践(九):储的实现:深入篇

早在年前的时候就已经在CSAI博客发表了上一篇文章:<仓储的实现:基础篇>.苦于日夜奔波于工作与生活之间,一直没有能够抽空继续探讨仓储的实现细节,也让很多关注EntityFramework和领域驱动设计的朋友们备感失望. 闲话不多说,现在继续考虑,如何让仓储的操作在相同的事物处理上下文中进行.DDD引入仓储模式,其目的之一就是能够通过仓储隐藏对象持久化的技术细节,使得领域模型变得更为"纯净".由此可见,仓储的实现是需要基础结构层的组件支持的,表现为对数据库的操作.在传统的关

EntityFramework之领域驱动设计实践(七):模型对象的生命周期

上文中已经提到了管理领域模型对象生命周期的两大角色,即工厂与仓储,并对工厂的EntityFramework实践作了详细的描述.本节主要介绍仓储的概念,由于仓储的内容比较多,我将在接下来的两节中具体讲解仓储的架构设计与实践经验. 仓储(Repository),顾名思义,就是一个仓库,这个仓库保存着领域模型的实体对象.在业务处理的过程中,我们有可能需要把正在参与处理过程的对象保存到仓储中,也有可能会从仓储中读取需要的实体对象,抑或将对象直接从仓储中删除.上文也用一张简要的状态图描述了仓储在管理领域模