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