domain-drive-design

DDD 领域驱动开发

领域模型---构造块---重构加深理解---战略

首先写下一个句子，然后将它分成小段，再将它们打乱并重新排序。仿佛是巧合一样，短语的顺序对意思完全没有影响。--Lewis Carroll,“Poeta Fit,Non Nascitur"

将模型作为语言的支柱。 确保团队在内部的所有交流中以及代码中坚持使用这种语言。 在画图、 写东西， 特别是讲话时也要使用这种语言。 大声的建模，改善模型的最佳方式之一就是通过对话来研究， 试着大声说出可能的模型变化中的各种结构。 这样不完善的地方很容易被听出来。

一个团队，一个语言。 UBIQUITOUS Language 务必要记住模型不是图。 图的目的是帮助表达和解释模型。

文档应作为代码和口头交流的补充。然而， 将代码作为设计文档也有局限性。 它可能会把读代码的人淹没在细节中。 文档不应再重复表示代码已经明确表达出的内容。 文档应当鲜活并保持最新 设计文档的最大价值在于解释模型的概念， 帮助在代码的细节中指引方向， 或许还可以帮助人们深入了解模型预期的使用风格。 通过将文档减至最少， 并且主要用它来补充代码和口头交流， 就可以避免文档与项目脱节。

良好的代码具有很强的表达能力， 但它所传递的信息不能确保是准确的。

本书的核心思想是在实现、 设计和团队交流中使用同一个模型作为基础。 如果各有各的模型， 将会造成危害.

由于模型是“正确的” ， 这是经过技术分析人员和业务专家大量协作才得到的结果， 因此开发人员得出这样的结论： 无法把基于概念的对象作为设计的基础。 于是他们开始进行专门针对程序开发的设计。 他们的设计确实用了一些原有模型中类和属性的名称进行数据存储， 但这种设计并不是建立在任何已有模型的基础上的。

另一方面， 许多复杂项目确实在尝试使用某种形式的领域模型， 但是并没有把代码的编写与模型紧密联系起来。 这些项目所设计的模型， 在项目初期还可能用来做一些探索工作， 但是随着项目的进展， 这些模型与项目渐行渐远， 甚至还会起误导作用。 所有在模型上花费的精力都无法保证程序设计的正确性， 因为模型和设计是不同的。

模型和程序设计之间的联系可能在很多情况下被破坏， 但是二者的这种分离往往是有意而为之的。 很多设计方法都提倡使用完全脱离于程序设计的分析模型， 并且通常这二者是由不同的人员开发的。 之所以称其为分析模型， 是因为它是对业务领域进行分析的结果， 它在组织业务领域中的概念时， 完全不去考虑自己在软件系统中将会起到的作用。 分析模型仅仅是理解工具， 人们认为把它与程序实现联系在一起无异于搅浑一池清水。 随后的程序设计与分析模型之间可能仅仅保持一种松散的对应关系。 在创建分析模型时并没有考虑程序设计的问题， 因此分析模型很有可能无法满足程序设计的需求。

分析工作一定要抓住领域内的基础概念， 并且用易于理解和易于表达的方式描述出来。 设计工作则需要指定一套可以由项目中使用的编程工具创建的组件， 使项目可以在目标部署环境中高效运行， 并且能够正确解决应用程序所遇到的问题。MODEL-DRIVEN DESIGN（ 模型驱动设计） 不再将分析模型和程序设计分离开，而是寻求一种能够满足这两方面需求的单一模型。 不考虑纯粹的技术问题， 程序设计中的每个对象都反映了模型中所描述的相应概念。 这就要求我们以更高的标准来选择模型， 因为它必须同时满足两种完全不同的目标。

软件系统各个部分的设计应该忠实地反映领域模型， 以便体现出这二者之间的明确对应关系。 我们应该反复检查并修改模型， 以便软件可以更加自然地实现模型， 即使想让模型反映出更深层次的领域概念时也应如此。 我们需要的模型不但应该满足这两种需求， 还应该能够支持健壮的BIQUITOUS LANGUAGE（ 通用语言）

MODEL-DRIVEN DESIGN发挥作用， 一定要在可控范围内严格保证模型与设计之间的一致性。 MODEL-DRIVEN DESIGN的两个基本要素（ 即模型要支持有效的实现并抽象出关键的领域知识）

ddd 的构造块

// 分层 用户界面层 应用层 领域层[状态] 基础设施层

// 领域驱动设计只有应用在大型项目上才能产生最大的收益， 而这也确实需要高超的技巧。 不是所有的项目都是大型项目； 也不是所有的项目团队都能掌握那些技巧。