推荐阅读：DDD领域驱动+设计模式 视频学习
这周学习了一些关于领域驱动设计的知识 ，对比较深刻的地方做了不少笔记，分享给大家。
在日常需求讨论的时候，经常会碰到一个需求会议开了一个多小时还没有达成共识。作为业务方（领域专家）明明表达的很清楚，但是开发人员却始终无法理解透彻，很明显的原因就是由于双方的知识体系不一致 ，没有形成一种双方互相都能理解的语言。
语言的鸿沟
虽然领域专家对软件开的技术所知有限，但他们熟悉使用自己的领域术语——可能还具有各种不同的风格。另一方面，开发人员可能会用一些描述性的，功能性的术语来理解和讨论系统，而这些术语并不具备领域专家的语言所要传达的意思。
开发人员可能会创建一些用于支持设计的抽象，但领域专家无法理解这些抽象。负责处理不同部分的开发人员可能会开发出各自不同的设计概念以及描述领域的方式。
由于语言上存在鸿沟，领域专家们只能模糊地描述他们想要的东西。开发人员虽然努力的理解一个自己不熟悉的领域，但也只能形成模糊的认识。
虽然少数团队成员会高法掌握这两种语言，但他们会变成信息流的瓶颈，并且他们的翻译也不准确。
相互翻译使模型变得混淆
在一个没有公共语言的项目上，开发人员不得不为领域专家做翻译。而领域专家要充当开发人员与其他领域专家之间的翻译。
这些翻译使模型概念变得混淆，而这会导致有害的代码重构。这种间接的沟通掩盖了分裂的形成——不同的团队成员使用不同的术语而尚不自知。
由于软件各个部分不能够浑然一体，因此这就导致无法开发出可靠的软件。翻译工作导致各类促进深入理解的知识和想法无法结合在一起。
不同语言产生的后果
如果语言支离破碎，项目必将遭遇严重的问题。领域专家使用他们自己的术语，而技术团队使用的语言则经过调整，以便从设计角度讨论领域。
日常讨论所使用的术语与代码中使用的术语不一致。甚至同一个人在讲话和写东西时使用的语言也不一致，这导致的后果是，对领域的深刻表述常常稍纵即逝，根本无法记录到代码或者文档 中。
翻译使得沟通不畅，并削弱了知识消化。 然而任何一方的语言都不能成为公共语言，因为它们无法满足所有的需求。
让领域模型成为公共语言
所有的程序的开销，连带着误解的风险，成本实在太高了。项目需要一种公共语言，这种语言要比所有的语言的最小公分母健壮得多。通过团队的一致努力，领域模型可以成为这种公共语言的核心，同时将团队沟通与软件实现紧密联系在一起。该语言将存在于团队工作中的方方面面。
最小公分母： 就是两个分母的最小公倍数,比如说2和3的最小公倍数是6,那么最小公分母就是6。
通用语言的词汇
通用语言的词汇包括类和主要的操作名称。语言中的术语，有些是用来讨论模型中已经明确的规则，还有些则来自施加于模型的的高级组织原则如：限界上下文、上下文映射图。
基于模型的语言
开发人员应该使用基于模型的语言来描述系统中的工件、任务和功能。这个模型应该为开发人员和领域专家提供一种用于相互交流的语言，而且领域专家还应该使用这种语言来讨论需求、开发计划和特性。语言使用得越普遍，理解进行得就越顺畅。
将模型作为语言的支柱。确保团队在内部的所有交流中以及代码中坚持使用这种语言，在画图、写东西、特别是讲话时也要使用这种语言。
领域专家应该抵制不合适或无法充分表达领域理解的术语或结构，开发人员应该密切关注那些将会妨碍设计的有歧义和不一致的地方 。
总结
在DDD的世界里，不管是作为领域专业还是开发人员，大家在讨论业务的时候都应该使用双方都能理解的语言。尽管在初期这种语言是晦涩难懂的，但随着项目的发展会慢慢渐入佳境。
空有通用语言其实不够，使用口头交流的方式，容易造成知识的丢失，也不利于项目未来的发展。应当建立模型，所有的讨论都是基于模型的，任何的的变更都要反映到模型上面。
