领域驱动设计系列(一):为何要领域驱动设计?

个人博客

前言

领域驱动设计最近貌似开始火起来了,越来越多的人开始认识到领域设计的重要性,从我做过的项目来看,似乎欧洲已经有很多的公司开始实施领域驱动设计了,我看领域驱动设计也有些时间了,但是网上不管是文章还是代码,都显得太过“高大上”,一谈领域驱动设计,一大堆的概念一股脑的给你上上来,搞的有点晕头转向,而我想在一些中小项目实施领域驱动也遇到了不小的障碍,大家对很多东西都处于一种恐惧的状态,而且在正真开始实施时,也遇到一些疑问,所以也想和大家交流学习,因此开始在此写写对领域驱动的理解,后面会有一些轻量的演进代码。

为何要领域驱动设计?

简化数据存储

领域驱动设计有很多原因,谈到我为啥要在公司推行领域驱动设计,说起来还是很好玩的,因为原来基于数据驱动的开发方式,也就是传统的多层开发架构,大家定义了一堆DAL来操作数据, 在.Net大家一般有两种使用方式,一种是用ORM像Entity Framework, 另一种想使用Dapper这样轻量级的Mapping工具,这些都要把关系型数据转换为对象。结果导致以下几种结果。

  • 没有正确的使用ORM, 导致数据加载过多,导致系统性能很差。
  • 为了解决性能问题,就不加载一些导航属性,但是确保DB Entity返回上层,这样对象的一些属性为空,上层使用这个数据时根本不知道什么时间这个属性是有值的,这个是很丑陋的是不是?
  • 如是又开始使用一些轻量级的数据方法,比如使用Dapper然后自己写SQL语句,这本来是很不错的方式,但是大部分人的SQL能力实在不敢恭维,大部分写出来的SQL语句,甚至比EnityFramework生成的语句还差。

所以,我就想我们做项目,大部分处理的应该是因为,如何让程序员从数据存储,模型转换的大泥潭里解放出来,领域驱动设计就进入了我的实现,当然但从数据这个角度还不足以选择领域驱动设计,用一个NoSQL数据库是不是就解决了? 但是NoSQL也有一些问题,比如MongoDB如何更优雅的保证事务以及数据的一致性等。

更多了解上下文

我们很多软件的问题,大家都知道是需求的问题,也就是客户的需求我们很难理解准确,导致程序员更加关注”HOW” 而忽略了”WHAT”, 最终做了几个礼拜甚至更长时间,结果客户会说:”What?! I told you”, 但是客户告诉我的,我们理解是不一样的。比如客户说:“ Great job, I love you!” 这个Love肯定不是男女之间的Love, 我们拿到的是一个客户的需求,他的上下文是什么? 比如说:“这个球打的好”, 如果是在打篮球,肯定说的事篮球,如果是在打乒乓球肯定说的是乒乓球。 而领域驱动设计里我们可以让业务人员更多的参与系统,更早的参与系统。

统一语言(Ubiquitous Language)

业务人员和我们使用一样的语言,我们的程序比如让业务尽量集中在领域里,比如在传统的数据驱动里,如果说Jack爱Rose, 我们一般会这么写

UserService.Love(Jack, Rose)

但是我们业务人员很奇怪谁Love谁? 为什么要UserService?, 如果我们写成下面这样

Jack.Love(Rose)

还有如果我们用

Company.hire(employee)

来代替

companyservice.hire(company,employee)

这样我们就更容易让业务人员参与进来,而且代码可以更易于表示真实的业务场景。

领域驱动设计 DDD

分享到:
评论加载中,请稍后...
创APP如搭积木 - 创意无限,梦想即时!
回到顶部