01｜领域驱动设计到底在讲什么？

课后题，个人YY： 1.文中其实没有对“统一语言”下定义。但以我的认知，“统一语言”是什么，确实不好明确定义，它并非一种固定格式的交付物，而是贯穿整个领域驱动设计时的多种元素。是沟通时达成共识的桥梁；是圈定限界上下文时划分聚合的依据；是设计领域模型时定义模型的参考；甚至是命名类名方法名的标准。 2.所以，与文中不同的是，我不认为是根据模型（领域模型）提取的统一语言。而是通过领域场景（这也算模型呀）分析，提炼出领域知识，共建整个系统的统一语言，而后才是建模（领域模型）。 3.如此一来，就是先有统一语言再有领域模型（之后还会相互影响，但感觉开始是这个顺序）。领域模型的抽象依赖统一语言做指导（类似于设计原则，在迷茫时引导你做决策）。如此，统一语言有它必须存在的价值在，所以不能拿掉。 4.那业务方可不可以直接使用模型？不可以，因为如果业务方直接使用模型，那么不管是知识的诅咒还是选择性偏见都可能促使业务方在讨论统一语言时，迁就或者受制于已有模型。这样在软件持续发展中，不利于统一语言的迭代（或则说掐死了很多可能性？）。 5.综上所述： 一个人脑袋里要同时有多个观点，并保持它们各自独立迭代发展是很难的。但有不同的几波人各自拿一个观点，然后再讨论合并，这样出来的统一语言相对应该会更客观些吧。不让业务方直接用模型也许是不想影响他们那波人脑袋中的观点吧。 问题： 案例里：“订阅”也只能表示专栏信息。感觉不大合适。 专栏多半是独立的聚合，毕竟专栏可以独立展示，订阅，做活动，这些行为都说明专栏有“完全民事行为能力”，所以它应该是个独立的聚合。所以用户维度的“订阅”应该是两个聚合的关联关系。失去用户，“订阅”是无法独立存在的概念，自然也不能表示任何东西。

业务操作模型的话，会导致模型和软件割裂，最终变为分析模型。更可怕的是一天一个想法，搞不好搞出百八十个模型都有可能。统一语言起到了屏蔽隔离保护作用，有点像网络分层，具体模型和软件实现由开发人员选取合适的方式实现。

不是很理解文中的例子，按例子说的设计方式，模型User要聚合不同业务场景下的不同实体，去订单、浏览记录、评论等，这样一个user模型不会变成巨无霸了吗？还是说，不同领域下都有自己的user模型，每个领域下的user模型聚合的实体都不一样？比如售卖领域，有名为User模型，他聚合了订单这个实体。评论领域，也有个名为User的模型，聚合了评论，提供了发布评论的接口？如果是这样的话，实际代码实现上，会不会出现大量的相似的重复的数据结构呢？比较困惑。

思考题： 个人认为根本原因是需要团队协作。首先模型是需要迭代的，迭代通常业务和技术一起讨论，讨论时每个人因为角色/背景/团队等的差异，会对同一个模型产生不同的理解。 通过统一语言，可以把对模型的认识和理解的差异消除。

模式是抽象的，没有实体，只能被表达。程序员用代码和文档表达模型，业务人员用统一语言表达模型。

我觉得，用统一语言的原因是，模型不好直接用语言描述，一个东西连名字都没有，怎么讨论呢

评论里有一些很牛的总结和想法，值得反复阅读品味，感觉极客时间缺少能让我们收藏的功能，或者统一查看自己点赞过的评论功能！

在工作过程中发现，实际上开发人员与业务人员沟通时，业务人员用自己的语言、名词描述自己的问题，开发人员用自己的语言、术语描述解决方案。沟通的过程中，可能开发人员根本就没有听懂问题，业务人员听解决方案更是云里雾里。 如果能把问题提炼成模型，通过模型去沟通，在沟通的过程中大家逐渐统一概念，统一语言。那么之后的讨论就会很快的理解对方的意思，也会得出更准确的解决方案

业务人员直接使用DDL算不算是直接使用模型呢？如果算的话，优点在于，如果模型质量高，DDL简单易用，通过DDL直接使用模型反而能大大提高效率。但缺点是，国内的业务人员有编程思维的人太少；DDL带来的多语言混杂重构调优不易；会有很多重要的领域概念被埋没在DDL的脚本中，导致模型僵化。

同样的字或话语，在不同时代或者不同的地区，因为背景的不一样，可能会具有差别比较大的含义，就连圣经中的上帝都会通过把语言搞得区别开，让人类语言不通无法协作，从而让巴别塔半途而废，由此可见统一语言的必要性。 每个人头脑中对的模型理解，我想就算不是千差万别，也不会是一目了然，再者好多人员并不能把自己的想法书面的表达到让其它人看得懂，这种时候就需要先通过讨论来达成共识，讨论是要有基础的，先统一语言可以避免歧义或鸡同鸭讲。