02｜统一语言是必要的吗？

课后问题思考: 领域驱动设计，逼着业务方和实现方像玩跷跷板一样共同构建业务系统，从协作角度看，这个游戏的特点是，【一个人没法玩】。 板≈共同语言，支点≈模型，以“支点”为中心，以“板”为媒介，双方你一下我一下地玩。 “板”+“支点”很大程度上定义了游戏的基本规则。

技术人员通过重构进而影响业务，这个观点很独到，但从自身经验而言确实匪夷所思。这个真的是有可能的吗？从技术角度出发的重构真的可以影响经验老道的业务人员吗？

上节留言是我错了： 1.特地翻了下蓝书。统一语言->模型的理解浅了（模型不等于是画出来的类图或则代码，而应该是消化知识时的思维模式的产物）。是我以前的认知偏差了，实际工作中多是和业务方讨论出统一语言，再对统一语言做实现，结果就愣是把认知扭曲成这个顺序了。关键的错误认知在于，误以为模型指的是基于与业务方沟通的结果做的解决方案和代码实现。熟不知，在与业务方沟通时，自己脑袋中基于建模的思维模式就将业务知识消化转换成模型定义，并直接以自己定义的模型的术语与业务方做沟通，待沟通结束，已经完成了 模型->统一语言 的推导。 课后题： 1.领域驱动设计分两块，第一块是通过两关联一循环的知识消化方式，理解业务知识，并反馈给合作方对应的模型定义，以达成认知共识和行为约束（业务方讲故事要基于统一语言，开发人员改代码要反映到统一语言上）。也就是常说的战略部分；第二块是通过一系列的编码风格或者说编程范式，构建以领域模型为核心的代码结构，保证领域模型的富类型以更好的表达统一语言，保证领域模型的干净以更好的应对变化坚守统一语言与代码模型的原子操作。也就是常说的战术部分。 2.领域驱动设计其实只是一系列软件开发过程的经验总结而成的方法论的总称，取这个名字主要因为这些方法论大多围绕领域业务为核心来设计模型和构建软件项目。可以说是来自字将的喜好。但也正应为领域驱动设计表达的是一个集合，所以现今流行的一些方法论也可以加入其中，只要是便于构建以领域业务为核心的软件项目这个目标，领域驱动设计的集合来着不惧。 个人疑问： 这么说统一语言是为了缓解开发和业务专家的认知差距？如果开发或者业务专家能完全理解业务和软件业务模型，就可以不需要统一语言？ 对于咨询行业来说，要应对众多的业务，每个都要成为专家显然不现实。但对于互联网大厂，很多业务或者开发在一个岗位一干就十来年，只要愿意学习，不管是开发掌握业务知识还是业务掌握软件模型显然都不是难事。那么还需要统一语言吗？现在，我认为统一语言其实只是一个别名，在开发与业务沟通的场合，所有双方的共同认知都属于统一语言（又是字将的喜好）。统一语言 ==（业务知识+软件模型）/共同认知。所以，可以不要统一语言直接用模型这个问题本身就有问题，毕竟有些时间统一语言就是模型，模型就是统一语言，不过是场景不同叫法不同。

我的总结：DDD领域驱动设计，是解决业务系统中，业务方和技术方沟通协同的问题。 它是从业务出发，以业务问题域为焦点，构造出与业务强相关的模型。 1.该模型既要关联软件开发，使得对模型的修改，就是对代码的修改。 2.又要关联统一语言，将业务方成为模型的使用者，统一语言驱动需求描述，驱动测试设计等。 3.通过技术方和业务方不断地交流与反馈中，提炼知识的循环，逐步完成对模型的淬炼。

麻烦大了，看不懂。

领域驱动设计我的理解是：以模型为中心和桥梁，连接并同步需求与实现，同时不断试错并修正的设计方式。

印象深刻的一点是领域语言建立了技术反馈业务的途径。不过在实操方面，就是实际工作中如何建立领域语言，有哪些技巧、方法和工具可以应用呢？

以前读书的时候学习管理信息系统时书中有提到系统的设计视角是 社会 - 技术 视角，统一语言就是那个 社会 的要达到的共识吧。

描述: 针对大型、复杂系统开发流程的一种解决方案。 领域驱动设计在逻辑设计上类似于结构化设计，自顶向下设计各个领域，由领域指导实现。 前置条件: 为实现领域驱动开发过程需各相关方人员在一起以业务需求出发建立统一语言，该语言是一个在组织环境、系统描述中各方各方都能接受的语言， 是在该组织或该项目下独有的且语义明确清晰的。 应用: 在确定统一语言后则可以进一步的以统一建模语言为基础提取出各方都确认的领域模型，由该模型的逻辑结构指导系统的实现，以达到实现与模型与需求相一致的目的。

我理解的DDD是击穿业务和技术的隔阂，让双方有共同的需要，减少业务和实现的偏差，技术更改了模型以后也能即使反馈给业务。另外一个是富含知识的代码，在显示中缺少业务和技术的文档，甚至代码注释都少，遗留系统非常难以维护，DDD能解决一部分的问题