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

Posted 2021-05-01 中生代技术

链接：http://www.jianshu.com/p/2223a7508683

來源：简书

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

通过当时的文章和解释我们不难看出实际上在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层中造成非常沉重难以拆分，但充血模型比较难以设计，需要有一定经验的设计师前期规划好，后期工作才能事半功倍，不然则会造成项目混乱。

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

实体	值对象
具有生命周期	起描述作用
有唯一标识	无唯一标识
通过ID判断相等性	实现equals方法
增删改查/持久化	即时创建用完就扔
可变	不可变
比如Order/Car	比如Address/Color

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

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

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

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

小结

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

参考文章
 
   
   
 

  
    
    
  
http://raychase.iteye.com/blog/1328224
https://www.cnblogs.com/xishuai/p/ddd-entity-value-object.html
 
   
   
 

---

特大喜讯！张逸老师即将在成都推出领域驱动设计公开课，两天的课程，4个单元，从了解领域驱动设计、战略式设计、战术式设计到领域建模实战演练，手把手教您进入领域驱动设计殿堂！

欢迎点击阅读原文了解详情

（以上图片来自DDD领域建模峰会，版权归组委会所有）