共计 1722 个字符，预计需要花费 5 分钟才能阅读完成。
大家好，我是霸戈，这周学习了一些对于 畛域驱动设计 的常识，对比拟粗浅的中央做了不少笔记，分享给大家。
在日常需要探讨的时候，常常会碰到一个需要会议开了一个多小时还没有达成共识。作为业务方（领域专家）明明表白的很分明，然而开发人员却始终无奈了解透彻，很显著的起因就是因为单方的常识体系不统一，没有造成一种单方相互都能了解的语言。
语言的鸿沟
尽管领域专家对软件开的技术所知无限，但他们相熟应用本人的畛域术语——可能还具备各种不同的格调。另一方面，开发人员可能会用一些描述性的，功能性的术语来了解和探讨零碎，而这些术语并不具备领域专家的语言所要传播的意思。
开发人员可能会创立一些用于反对设计的形象，但领域专家无奈了解这些形象。负责解决不同局部的开发人员可能会开发出各自不同的设计概念以及形容畛域的形式。
因为语言上存在鸿沟，领域专家们只能模糊地形容他们想要的货色。开发人员尽管致力的了解一个本人不相熟的畛域，但也只能造成含糊的意识。
尽管多数团队成员会高法把握这两种语言，但他们会变成信息流的瓶颈，并且他们的翻译也不精确。
互相翻译使模型变得混同
在一个没有公共语言的我的项目上，开发人员不得不为领域专家做翻译。而领域专家要充当开发人员与其余领域专家之间的翻译。
这些翻译使模型概念变得混同，而这会导致无害的代码重构。这种间接的沟通覆盖了决裂的造成——不同的团队成员应用不同的术语而尚不自知。
因为软件各个局部不可能浑然一体，因而这就导致无奈开发出牢靠的软件。翻译工作导致各类促成深刻了解的常识和想法无奈联合在一起。
不同语言产生的结果
如果语言四分五裂，我的项目必将遭逢重大的问题。领域专家应用他们本人的术语，而技术团队应用的语言则通过调整，以便从设计角度探讨畛域。
日常探讨所应用的术语与代码中应用的术语不统一。甚至同一个人在讲话和写货色时应用的语言也不统一，这导致的结果是，对畛域的粗浅表述经常昙花一现，根本无法记录到代码或者文档 中。
翻译使得沟通不畅，并减弱了常识消化。 然而任何一方的语言都不能成为公共语言，因为它们无奈满足所有的需要。
让畛域模型成为公共语言
所有的程序的开销，连带着误会的危险，老本切实太高了。我的项目须要一种公共语言，这种语言要比所有的语言的最小公分母强壮得多。通过团队的统一致力，畛域模型能够成为这种公共语言的外围，同时将团队沟通与软件实现紧密联系在一起。该语言将存在于团队工作中的方方面面。
最小公分母：就是两个分母的最小公倍数, 比如说 2 和 3 的最小公倍数是 6, 那么最小公分母就是 6。
通用语言的词汇
通用语言的词汇包含类和次要的操作名称。语言中的术语，有些是用来探讨模型中曾经明确的规定，还有些则来自施加于模型的的高级组织准则如：限界上下文、上下文映射图。
基于模型的语言
开发人员应该应用基于模型的语言来形容零碎中的工件、工作和性能。这个模型应该为开发人员和领域专家提供一种用于互相交换的语言，而且领域专家还应该应用这种语言来探讨需要、开发计划和个性。语言应用得越广泛，了解进行得就越顺畅。
将模型作为语言的支柱。确保团队在外部的所有交换中以及代码中保持应用这种语言，在画图、写货色、特地是讲话时也要应用这种语言。
领域专家应该抵制不适合或无奈充沛表白畛域了解的术语或构造，开发人员应该亲密关注那些将会障碍设计的有歧义和不统一的中央。
总结
在 DDD 的世界里，不论是作为畛域业余还是开发人员，大家在探讨业务的时候都应该应用单方都能了解的语言。只管在初期这种语言是艰涩难懂的，但随着我的项目的倒退会缓缓渐入佳境。
空有通用语言其实不够，应用口头交换的形式，容易造成常识的失落，也不利于我的项目将来的倒退。该当建设模型，所有的探讨都是基于模型的，任何的的变更都要反映到模型下面。
举荐
- 分享一套家庭理财零碎（附源码）
- 举荐一套开源通用后盾管理系统（附源码）
- 举荐一个酷炫的监控零碎
- 从敌人那里搞了 20 个实战我的项目，速领！
- 举荐一个欠缺的停车管理系统，物联网我的项目 springboot，附源码
- 举荐一个互联网企业级别的开源领取零碎
- 一款神仙接私活儿软件，吊到不行！
- 举荐 10 款超实用的企业级开源利用！
- 开放平台 SDK 设计实际！
- “淘宝”开放平台接口设计思路
- Spring 中经典的 9 种设计模式