《领域驱动设计》一书是领域模型领域的代表作，被很多牛人推荐，其中的概念还需要在思考和实践中逐步理解。书中描述的一些现象有些与我们类似，比如越来越多的领域规则被嵌入到查询代码中，或者直接就不见了。领域逻辑跑到查询代码和客户代码中去了，而实体和值对象变成了纯粹的数据容器。大部分数据访问基础结构的技术复杂性，很快使得客户代码陷入混乱，最终开发人员只好抛弃领域层，把模型变成一个摆设。以下将针对一些非技术问题进行一些记录，方便以后查阅思考。

    * 如果程序员对领域较为熟悉，他们便可以使得软件保持能够继续扩展的良好状态，但是如果程序员对于该领域不敢兴趣，他们知道应用程序应该做什么，却不了解其背后的原理。这样做虽然能够建立一个有用的软件，但是项目永远不会具有能够从前期特征能推导出更加强大的新特征的能力。

    * 领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点，它很适合作为这种通用语言的构造基础。

    * 很多原因都会造成软件开发的复杂性，然而其核心则是由于问题领域本身的复杂性。控制复杂问题的关键是建立一个好的领域模型，它越过问题域的表象介绍其底层的结构，给软件开发人员提供所需的方法。

    * 模型驱动设计不仅要求我们的设计能够将概念表达出来，还应该能够被高效的实现。一个领域模式不仅仅是用UML图表达出来的优雅的想法，它还应该为模型驱动设计中的某个编程问题提供解决方案。当我们的模型应该恰当时，我们就可以深入下去，挖掘出一整套解决某种领域建模问题的思路。而且，这种寻找高效实现的经验的不断积累，也能使我们受益匪浅。

    * 软件的最终目的是为用户提供服务，但是，它首先必须为开发人员服务。如果软件的行为非常复杂，但是又缺乏良好的设计，那它就会变得难以重构和组合。由于开发人员不能够确切的预知计算的全部内涵，重复问题就产生了。如果设计元素都是整块的、无法重新组合的部分，重复就是不可避免的了。我们可以对那些类和方法进行分解使之便于重用，但这样一来各个小部分分别有什么作用又变得难以跟踪了。一个缺乏清晰设计的软件，单是看到其中的混乱结构就会让开发人员头脑发晕，更不用说对设计进行修改（那只会使设计更加混乱），有时甚至会由于意料之外的依赖关系而导致设计完全无法工作。这种脆弱性导致我们无法构造出行为更加丰富的系统（除非系统的规模相当小），也阻碍了重构和迭代精化的进行。

    * 随着项目开发的进行，我们应该感到速度越来越快，而不是感到包袱越来越层沉。这就要求我们的设计能让人乐于使用，也能很容易的适应改变。这就是柔性设计。

    * 模型的选择取决于3个基本的用途： 模型与设计核心的相互塑形、模型是所有团队成员所使用语言的核心、模型用来提炼知识

    * 知识消化并不是一个孤立的活动，它是由开发团队与领域专家共同合作，由开发人员领导的。知识消化过程必须探索模型选项，并将它们精化为使用的软件元素。

    * 那些没有领域模型，只是靠编写代码来完成一个又一个功能的项目，不能获得知识消化与交流带来的益处。

    * 领域模型的不断精化使得开发人员不断地学习他们的重要业务原理，而不是机械的产生新的功能。

    * 模型关注的是需求分析，它与编程和设计相互影响。

    * 重组会打散团队，知识也会再次分散。仅仅交付了代码而没有传递知识的工作方式使得一些关键的子系统无据可依。使用典型的设计方法时，代码和文档都不能用有效的方式表达出人们辛苦得到的知识，因此当这种口头上的惯例由于任何原因被打破时，知识也就遗失了。

    * 高效率的团队依靠学习，有意识的增长自己的知识，这意味着提高技术知识以及一般的领域建模技能，也包括学习所从事的特定领域。

    * 使用术语及关系来反映领域的内涵。基于模型的交流提高编写文档的实用性。

    * 要将模型作为语言的骨干。使用了通用语言，模型就不仅仅是一个设计工作了。它整合到开发人员与领域专家所做的每一件事中。

    * 一定要记住模型并不是图，图的目的是帮助表达和解释模型。

    * 说明性模型的图形带有它所表示模型的自然语言解释。一起查看两种图形（说明性模型和类图模型）要比单独查看任何一种更容易理解。

    * 一个缺乏设计基础概念的软件最多只能是一个能够做游泳的事情却不能清楚解释它的行为的机械装置。

    * 建模与编程的完全分离是不可行的。

    * 纯粹的分析模型甚至不能够达到其理解领域的主要目标，因为重要的发现往往出现在设计/实现过程中。模型驱动设计抛弃了分裂分析模型与设计的做法，而是寻找一个单独的模型来满足着两方面的要求。

    * 将分析、建模、设计和编码的职责完全隔离起来，会阻碍模型驱动设计。分开会造成：交接时遗漏了模型的一些意图；模型与实现和技术之间的相互作用个所得到的反馈过于间接。

    * 负责建模的技术人员必须花时间接触代码，而不论他是否在项目中担当主要角色。任何负责代码修改的人员都必须学习通过代码表达模型。每个开发人员都必须参与一些级别的模型讨论中，并与领域专家接触。

    * 解决来自领域方面的软件部分通常只占整个软件系统的一小部分，这与它的重要性相比是不成比例的。我们需要把领域对象跟系统的其他功能分离出来，才能够避免将领域概念与其他软件技术相关的概念混淆或者在系统的庞大中失去了对领域的把握。

    * 是领域层而不是应用层负责提供基本的规则。

    * 在应用一个框架是，开发团队应该首先明确它的目标：创建一个实现来表示一个领域模型并且用这个实现来解决重要的问题。

    * 不受限制的数据库查询实际上会破坏领域对象和聚合的封装。

    * 一般来说，不要与框架对着干。寻找合适的方法来保持领域驱动设计的基本方向。如果框架与设计发生矛盾的话，在一些细节问题上顺其自然。寻找领域驱动设计的概念与框架概念有哪些相近之处。当然，这里的假设是我们除了使用该框架之外别无选择。

    * 建模和设计不是一个匀速向前的过程，如果不频繁重构，利用新的理解来改进模型和设计，我们就会逐渐变的寸步难行。

    * 约束构成了模型概念中特别重要的一种类型。

    * 流程是应该被显示的描述出来还是应该隐藏起来？区分的要点很简单：这个流程是领域专家所谈论的流程，还是仅仅是计算机程序机制的一部分？