DDD原著 -- 第二章 语言的交流和使用

前端之家收集整理的这篇文章主要介绍了DDD原著 -- 第二章 语言的交流和使用前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。

一个团队,一种语言!

  1. 语言,术语的统一很重要。如果语言支离破碎,项目必将遭遇严重问题。 讨论与写代码中术语不一致,甚至同一个人说的跟写时不一致,导致对领域有一定的理解认识,也转眼忘记,无法记录到代码与文档中。
  2. 项目需要一种公共语言,领域模型可以成为这种语言的核心。公共语言是整个团队工作中的通用语言(Ubiquitous Language)。
  3. Ubiquitous Language的词汇表包括名称和主要操作。
  4. 模型之间的关系成为所有语言都具有的组合规则。词和短语的意义反映了模型的语义。术语=>规则、大比例结构、ContextMap
  5. 知识消化 –> 模型完善 –> 术语意义改变或新术语增加
  6. 将模型作为语言的重心,确保团队在所有交流活动中坚持使用这种语言。画图、写东西、讲话… 需要解决术语混淆的问题及有歧义的不一致的地方。Ubiquitous Language以动态形式传递知识。
  7. 精华模型的最佳方式之一就是通过对话来研究,找出可能的模型变化,并说出对他的多种构想。这样不完善的地方很容易被听出来。
  8. 讨论系统时需要结合模型。使用模型的元素以及模型中各元素之间的交互大声描述场景,并且按照模型允许的方式将各种概念结合到一起。找到更简单的表达方式来讲出你要讲的话,然后将这些新的思想应用到图和代码中。
  9. UML有时过于细致,有时很多遗漏。
  10. 图是一种沟通和解释手段。(简洁的小图可以很好的实现这目标)
  11. 图和文档能够引导人们将注意力放在核心要点上。通常的做法是以图为主,辅以文本注释。而我更喜欢以文本为主,添加精心挑选的简化图作为注释。
  12. 务必要记住模型不是图。图的目的是帮助表达和解释模型。(代码可以充当设计细节的存储库,清晰的代码与UML具有同样的表达能力。)
  13. 文档只是作为代码和口头的交流的补充。但代码作为一种设计文档,自身也存在局限性。他能把读代码的人淹没在细节中。
  14. 文档不应再重复表示代码已经明确表达出的内容。应着重说明含义,以便使人们能够深入理解大比例结构,并将注意力集中在核心元素上。
  15. Ubiquitous Language可使文档更简洁和明确。
    当领域模型反映了与业务最相关的知识时,应用程序的需求成为该模型内部场景而Ubiquitous Language可用于描述这样一个直接与Model-Driven Design有关的场景。结果就是规格说明等文档的编写更加简单,t因为他们不必传达模型背后隐含的业务知识。
  16. 通过将文档减至最少,并且主要用它来补充代码和口头交流,就可以避免文档与项目脱节。根据Ubiquitous Language及其演变来选择那些需要保持最新并与项目活动紧密交互的文档。
  17. XP完全依赖可执行代码代码测试。但方法名称可能会有歧义,会产生误导或者因为已经过时而无法表示方法的本质含义。消除歧义是声明式设计。要使代码所传达的消息与他的行为和意图保持一致,要有严格的设计规程和特定的思考方式。
  18. 解释性模型不等于对象模型(技术模型)。 技术模型必须经过严格的精简,以便用最小的模型来实现其功能。 解释性模型可引入其他视图、工具等,只是为传递一般领域知识的教学工具。
原文链接:https://www.f2er.com/javaschema/283810.html

猜你在找的设计模式相关文章