开发人员：这样也没有问题，服务对数据的操作很容易，咱们先清除放弃的销售地区，等到找到替换的销售地区我们再去添加也是一样的。
用户：可以，因为我们每次的制定一份销售计划需要花费很大的人力物力，一般情况下对于销售方案部门不想去更改。
开发人员：我们通过销售方案服务查询出要放弃地区的销售方案信息进行列表显示，然后与新地区的销售方案进行一个对比，看看是否有没有制定新的销售方案的必要。
用户：我明白了。
现在很多开发团队使用的对话方案，看起来完成用户的需求也是没有问题的。
用领域模型进行讨论：
用户：当我的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）代码的时候也会方面很多。通用语言使用的越多记忆越牢固。