领域驱动（1）认识了解什么是领域驱动
废话
领域驱动设计已经出现很早了，说实话很早以前的我很不喜欢看书、不论是pdf还是书本、买过的书籍还是有几本的，这仅有的几本书还是因为公司的业务或者某项技术遇到瓶颈需要自己和团队进行突破的时候用来填充自己的大脑用的，当然这是被动的，毕竟：生下来、活下去很重要的。这两年微服务的出现好像又推动了领域驱动设计的发展。
一、解释什么是领域驱动：
其实对于IT的行业的我们理解起来很容易，很有可能在日常生活工作中我们也都有过接触，对于领域是一个什么样的概念
举例：
比如说我们要做一个有关用户登录的功能，使用最简单的RBAC来进行设计但是在进行设计的时候我们首先需要明白的是用户（甲方）有几种级用户的级别，每种级别处于什么样的角色，又有多少权限，这个时候产品经理开始去接触软件使用方（方法），去了解他们的需求以及，期初因为产品经理不明白甲方的企业架构导致采集需求的时候工作异常难做，摩擦不断，后来渐渐的接触的多了，明白了甲方的企业架构，并且对甲方的一些专业的称呼、名词也渐渐的懂得了，在往后的沟通过程中双方之间的摩擦也渐渐的少了起来。 在这个由坏变好的过程中，是因为产品经理渐渐的融入了甲方的领域内。
然后产品把业务拿了回来，软件开发人员开始了设计开发工作，大多数开发人都把技术作为自己的能力，对领域并不去了解，导致了后来功能实现后，代码不能很好的扩展，有一天产品经理拿了一份变更的需求回来了，为了实现新的需求，迫不得已软件开发人员只有重新来过，导致了前面做的很多工作都是无用工，我相信这样的场景很多的开发人员都遇到过，也埋怨过，其实我们也是有错的假如我们开发人员也同样进入了对方的领域中，在真正的实现过程中，就可能会提前发现隐藏的问题，再不济也能写出可扩展的设计或代码，当真正的发生变更的时候，也不至于前面的所有的工作都成为了无用功。
其实领域驱动设计需要领域驱动专家和开发人员相互协作来完成的，在这个过程中无论是开发人员还是业务人员都积累了该领域的相关知识。
但是在开发过程中，时长会有人员流失的可能性，其实人员的流失也是相对应的领域知识的流失，有人这样说，真正的高手写出的代码是可以让菜鸟维护器来都不是很吃力的，为什么呢，其实高手在写代码的时候已经传承下了该领域的知识，等到新人来到的时候，根据代码分析学习代码中传承下的领域知识，可以做到更快的了解业务。
代码举例：利用策略模式实现一个简单的领域模型
用一个比较靠近生活的例子：一套服装的价格在不同的地区出售不同的价格
我们把地区和服装的价格联系起来
/// <summary> /// 获取衣服价格 /// </summary> /// <returns></returns> public decimal GetClothing(string ClothingNO, string AreaNo) { ClothingModel clothingModel = new ClothingModel(); SellAreaModel sellAreaModel = SellAreaModellist.Where(x => x.AreaNo == AreaNo).SingleOrDefault(); if (sellAreaModel != null) { clothingModel = ClothingModellist.Where(x => x.ClothingNo == ClothingNO&& x.AreaNo==sellAreaModel.AreaNo).SingleOrDefault(); //乘以折扣比率 return clothingModel.ClothingPrice* clothingModel.Discount; } else { return 0.00M; } }