领域驱动设计（2）怎么使用沟通

废话

沟通的重要性：沟通很重要，不论在生活中，还是工作中沟通处理不好，我想为人处事这块肯定有问题.LZ接触社会比较早，做过焊工、销售、跑过业务...，一路走来在沟通上同样的也吃过很多的亏，受了不少的不会沟通的害处。我在做业务的时候常常用一句话告诫自己“一句话能死，一句话能活”，可能因为一句话业务活了，可能一句话面试活了，可能一句话感情有了....可能性很多，其实这可能的情况都是机遇只不过有大有小罢了.

领域驱动设计中的沟通：

有很多的项目是处于这一种情况,甲方（也就是领域驱动中的专家）不懂技术，不懂什么是开发，没有开发的思想，唯一知道的是我想要什么的系统、功能或产品。因为领域驱动提倡的是开发人员和领域专家有交流和沟通的，那么在平常开发的过程中常常会有这样的事情发生，业务人员和甲方沟通过业务之后，把需求带了回来，开发人员根据对甲方业务需求的分析进行设计开发，功能完成后，甲方验收的时候发现不是自己想要的结果，这样的后果在做项目的角度上无疑是非常严重的，不仅仅是延长了项目的完工时间，同样也打压了团队的气氛以及积极心态，为什么会造成这样的事情的发生，会不会是甲方描述的不清楚，也或者说是不是业务描述在传递的过程中有丢失...等等@可能有些人不认同了，为什么没有形成需求文档让用户签字确认等一些正规操作，这里举例说明的问题是相互沟通，相互了解。事实上一些好产品经理、团队会和用户进行深入的业务探讨，往往针对一个需求，你来我往的战斗几轮后才会产出需求、不管是反驳还是提出各种疑问或者是使用各种方法，如头脑风暴、用户故事、原型图引导。。。等手段，这样的深层次的沟通才会产出更加准确的需求，以此来减少需求的更改，也为项目的顺利的验收埋下了因，而不是签字确认需求为以后甩锅做准备。

在这种深层次沟通的情况下我们（乙方）讲渐渐的融入进甲方的领域中，这个过程中我们积累了很多无形的财富，比如在公共语言上（在领域驱动设计中称为：UBIQUITOUS LANGUAGE 通用语言）将达成一致，当甲方使用他们自己的行话进行沟通的时候我们将不再迷茫，在种情况下进行沟通我们便可绘制出更加准确的模型，模型与模型之间的关系构建出了业务的规则，一些词和短语也将反映出模型的含义。当所有的项目干系人都使用基于模型的语言来进行沟通交流，模型语言使用的越普遍，理解就越容易。切记的是在构建模型的过程中使用的通用语言应避免那些绕口、语义表述不正确的词或语句，如果发现需尽快找到替代的词或语句，通用语言越普通越贴近生活越容易理解。

举例说明领域驱动设计语言如何使用

以下会出两个例子做一个对比：

（1）没有使用领域语言是这样沟通的

新建四张表

一个简单的用户请求领域

在沟通过程中一般是这样沟通的：

用户：当我的销售地区（Area）发生更改的时候，需要重新制定销售方案吗？

开发人员：是的销售区域发生改变的时候我们需要删除销售方案表(SalesScheme)中的所有有关该地区的方案信息。然后将新的地区的信息通过服务去删除然后重新制定新地区的销售方案信息.

用户：明白了，你们是删除数据行项目，然后去插入行项目，但是如果我刚开始，我只知道哪些销售地区需要需要放弃，但是我还不知道替换成哪些销售地区怎么办呢，毕竟每个地区销售的策略是不一样的。

开发人员：这样也没有问题，服务对数据的操作很容易，咱们先清除放弃的销售地区，等到找到替换的销售地区我们再去添加也是一样的。

用户：可以，因为我们每次的制定一份销售计划需要花费很大的人力物力，一般情况下对于销售方案部门不想去更改。

开发人员：我们通过销售方案服务查询出要放弃地区的销售方案信息进行列表显示，然后与新地区的销售方案进行一个对比，看看是否有没有制定新的销售方案的必要。

用户：我明白了。

现在很多开发团队使用的对话方案，看起来完成用户的需求也是没有问题的。

用领域模型进行讨论：

用户：当我的Area（销售地区）发生更改的时候，需要重新制定销售方案吗？

开发人员：是的Aera（销售地区）发生改变的时候我们需要删除SalesScheme(销售方案表)中的所有有关该Aera（销售地区）的方案信息。然后将新的Aera的Scheme（方案）信息通过SalesSchemeService(销售方案服务)去删除然后重新插入新的销售方案信息.到SalesScheme(销售方案表)中。

用户：明白了，你们是删除SalesScheme(销售方案表)行项目，然后去插入行项目，但是如果我刚开始，我只知道哪些Aera（销售地区）需要需要放弃，但是我还不知道替换成哪些Aera（销售地区）怎么办呢，毕竟每个地区销售的策略是不一样的。

开发人员：这样也没有问题，SalesSchemeService(销售方案服务)对数据的操作很容易，咱们先清除放弃的Aera（销售地区），等到找到替换的Aera（销售地区）我们再去添加也是一样的。

用户：可以，因为我们每次的制定一份Scheme（方案）需要花费很大的人力物力，一般情况下对于Scheme（方案）不想去更改。

开发人员：我们通过SalesSchemeService(销售方案服务)查询出要放弃Aera（销售地区）的Scheme（方案）信息进行列表显示，然后与新地区的Scheme（方案）进行一个对比，看看是否有没有制定新的Scheme（方案）的必要。

用户：我明白了。

这是模拟针对同一个业务需求用不同的方式进行的相互讨论，有人会想了你这不是换了一种交流方式吗？我们开发设计上也是这么做的啊，事实上很多公司都在这么做，但是因为一些特殊的原因导致我们开发人员是接触不到甲方的，大多数的场景都是通过项目经理或者产品经理给我们描述，其实换一种角度，项目经理/产品经理把甲方当做领域专家，开发人员也可以把项目经理/产品经理当做领域专家，其实这样做也避免了很多摩擦风险，把很多愉快和不愉快的事情控制在了项目内部，但是在项目内部使用领域的UBIQUITOUS LANGUAGE（通用语言）去沟通避免了对同一个业务不同的人产生不同的理解，开发人员不在使用自己的语言去沟通去设计，使用同一种语言去沟通，是开发人员之间省去了不必要的翻译工作，在和项目组其他干系人去沟通的时候很少会出现（听不懂、你再说一遍、等一下我记一下、来麻烦重新描述一下、你看我这样理解对不对呢、等等）这样的情况，因为使用同一种语言描绘出的业务，大家都会明白的，这样对执行效率、准确性以及代码质量会有很大的提升。就是相互之间请别人帮忙查看一下（code review）代码的时候也会方面很多。通用语言使用的越多记忆越牢固。

在我的真正项目经历中令我印象最深的一次是，我们的主系统，是有很多个子系统组成的，我们项目组负只责其中一个系统模块，同时参与该系统的还有多个团队，所有子系统的功能性测试已经完成，要进入流程性测试的时候，再一次会议上发生了这样的事情，甲方在很卖力讲测试业务流程的时候我很惊奇的发现在场的大多数人员都处于一个懵逼状态，当然也包括我（哈哈）举个例子：在做一个反向订单业务的时候我们在项目中称为“反向订单”，到甲方这里称为“散件入库”这只是其中的一个，总之当时给我的感觉就是我是不是进错会议室了。

当然模型的制定不会是那么顺利的，这个过程相当于让甲方学习了一门新的语言了，但是如果在项目的一开始我们就带入模型的概念，从文档，原型、示例图、PPT、各种图、会议上等都带入模型的概念，慢慢的也都习惯了，时间长了大家就都会认为这是合理的了，时间能消磨很多棱角的。

OK

最近一两个月将持续更新领域驱动设计。有偏差的望大家指出，相互学习。

有不足之处 希望大家指出相互学习，

本文原创：转载请注明出处 谢谢！