领域驱动设计系列（一）:为什么要领域驱动设计？

前言

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

为什么要领域驱动设计？

简化数据存储

领域驱动设计有不少缘由，谈到我为啥要在公司推行领域驱动设计，提及来仍是很好玩的，由于原来基于数据驱动的开发方式，也就是传统的多层开发架构，你们定义了一堆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)

这样咱们就更容易让业务人员参与进来，并且代码能够更易于表示真实的业务场景。