领域驱动设计（2）怎么使用沟通 废话
沟通的重要性：沟通很重要，不论在生活中，还是工作中沟通处理不好，我想为人处事这块肯定有问题.LZ接触社会比较早，做过焊工、销售、跑过业务...，一路走来在沟通上同样的也吃过很多的亏，受了不少的不会沟通的害处。我在做业务的时候常常用一句话告诫自己“一句话能死，一句话能活”，可能因为一句话业务活了，可能一句话面试活了，可能一句话感情有了....可能性很多，其实这可能的情况都是机遇只不过有大有小罢了.
领域驱动设计中的沟通：
有很多的项目是处于这一种情况,甲方（也就是领域驱动中的专家）不懂技术，不懂什么是开发，没有开发的思想，唯一知道的是我想要什么的系统、功能或产品。因为领域驱动提倡的是开发人员和领域专家有交流和沟通的，那么在平常开发的过程中常常会有这样的事情发生，业务人员和甲方沟通过业务之后，把需求带了回来，开发人员根据对甲方业务需求的分析进行设计开发，功能完成后，甲方验收的时候发现不是自己想要的结果，这样的后果在做项目的角度上无疑是非常严重的，不仅仅是延长了项目的完工时间，同样也打压了团队的气氛以及积极心态，为什么会造成这样的事情的发生，会不会是甲方描述的不清楚，也或者说是不是业务描述在传递的过程中有丢失...等等@可能有些人不认同了，为什么没有形成需求文档让用户签字确认等一些正规操作，这里举例说明的问题是相互沟通，相互了解。事实上一些好产品经理、团队会和用户进行深入的业务探讨，往往针对一个需求，你来我往的战斗几轮后才会产出需求、不管是反驳还是提出各种疑问或者是使用各种方法，如头脑风暴、用户故事、原型图引导。。。等手段，这样的深层次的沟通才会产出更加准确的需求，以此来减少需求的更改，也为项目的顺利的验收埋下了因，而不是签字确认需求为以后甩锅做准备。
在这种深层次沟通的情况下我们（乙方）讲渐渐的融入进甲方的领域中，这个过程中我们积累了很多无形的财富，比如在公共语言上（在领域驱动设计中称为：UBIQUITOUS LANGUAGE 通用语言）将达成一致，当甲方使用他们自己的行话进行沟通的时候我们将不再迷茫，在种情况下进行沟通我们便可绘制出更加准确的模型，模型与模型之间的关系构建出了业务的规则，一些词和短语也将反映出模型的含义。当所有的项目干系人都使用基于模型的语言来进行沟通交流，模型语言使用的越普遍，理解就越容易。切记的是在构建模型的过程中使用的通用语言应避免那些绕口、语义表述不正确的词或语句，如果发现需尽快找到替代的词或语句，通用语言越普通越贴近生活越容易理解。
举例说明领域驱动设计语言如何使用
以下会出两个例子做一个对比：
（1）没有使用领域语言是这样沟通的
新建四张表
在沟通过程中一般是这样沟通的：
用户：当我的销售地区（Area）发生更改的时候，需要重新制定销售方案吗？
开发人员：是的销售区域发生改变的时候我们需要删除销售方案表(SalesScheme)中的所有有关该地区的方案信息。然后将新的地区的信息通过服务去删除然后重新制定新地区的销售方案信息.
用户：明白了，你们是删除数据行项目，然后去插入行项目，但是如果我刚开始，我只知道哪些销售地区需要需要放弃，但是我还不知道替换成哪些销售地区怎么办呢，毕竟每个地区销售的策略是不一样的。