为何要领域驱动设计
领域驱动设计备忘录:
参考:https://www.cnblogs.com/cnblogsfans/p/4284462.html#undefined
前言
领域驱动设计最近貌似开始火起来了,越来越多的人开始认识到领域设计的重要性,从我做过的项目来看,似乎欧洲已经有很多的公司开始实施领域驱动设计了,我看领域驱动设计也有些时间了,但是网上不管是文章还是代码,都显得太过“高大上”,一谈领域驱动设计,一大堆的概念一股脑的给你上上来,搞的有点晕头转向,而我想在一些中小项目实施领域驱动也遇到了不小的障碍,大家对很多东西都处于一种恐惧的状态,而且在正真开始实施时,也遇到一些疑问,所以也想和大家交流学习,因此开始在此写写对领域驱动的理解,后面会有一些轻量的演进代码。
为何要领域驱动设计?
领域驱动设计有很多原因,谈到我为啥要在公司推行领域驱动设计,说起来还是很好玩的,因为原来基于数据驱动的开发方式,也就是传统的多层开发架构,大家定义了一堆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, 我们拿到的是一个客户的需求,他的上下文是什么? 比如说:“这个球打的好”, 如果是在打篮球,肯定说的事篮球,如果是在打乒乓球肯定说的是乒乓球。 而领域驱动设计里我们可以让业务人员更多的参与系统,更早的参与系统。