《领域驱动设计》书评

部分笔记摘要

《领域驱动设计》一书是领域模型领域的代表作，被很多牛人推荐，其中的概念还需要在思考和实践中逐步理解。书中描述的一些现象有些与我们类似，比如越来越多的领域规则被嵌入到查询代码中，或者直接就不见了。领域逻辑跑到查询代码和客户代码中去了，而实体和值对象变成了纯粹的数据容器。大部分数据访问基础结构的技术复杂性，很快使得客户代码陷入混乱，最终开发人员只好抛弃领域层，把模型变成一个摆设。以下将针对一些非技术问题进行一些记录，方便以后查阅思考。* 如果程序员对领域较为熟悉，他们便可以使得软件保持能够继续扩展的良好状态，但是如果程序员对于该领域不敢兴趣，他们知道应用程序应该做什么，却不了解其背后的原理。这样做虽然能够建立一个有用的软件，但是项目永远不会具有能够从前期特征能推导出更加强大的新特征的能力。* 领域驱动设计的一个核心的原则是使用一种基于模型的语言。因为模型是软件满足领域的共同点，它很适合作为这种通用语言的构造基础。* 很多原因都会造成软件开发的复杂性，然而其核心则是由于问题领域本身的复杂性。控制复杂问题的关键是建立一个好的领域模型，它越过问题域的表象介绍其底层的结构，给软件开发人员提供所需的方法。* 模型驱动设计不仅要求我们的设计能够将概念表达出来，还应该能够被高效的实现。一个领域模式不仅仅是用UML图表达出来的优雅的想法，它还应该为模型驱动设计中的某个编程问题提供解决方案。当我们的模型应该恰当时，我们就可以深入下去，挖掘出一整套解决某种领域建模问题的思路。而且，这种寻找高效实现的经验的不断积累，也能使我们受益匪浅。* 软件的最终目的是为用户提供服务，但是，它首先必须为开发人员服务。如果软件的行为非常复杂，但是又缺乏良好的设计，那它就会变得难以重构和组合。由于开发人员不能够确切的预知计算的全部内涵，重复问题就产生了。如果设计元素都是整块的、无法重新组合的部分，重复就是不可避免的了。我们可以对那些类和方法进行分解使之便于重用，但这样一来各个小部分分别有什么作用又变得难以跟踪了。一个缺乏清晰设计的软件，单是看到其中的混乱结构就会让开发人员头脑发晕，更不用说对设计进行修改（那只会使设计更加混乱），有时甚至会由于意料之外的依赖关系而导致设计完全无法工作。这种脆弱性导致我们无法构造出行为更加丰富的系统（除非系统的规模相当小），也阻碍了重构和迭代精化的进行。* 随着项目开发的进行，我们应该感到速度越来越快，而不是感到包袱越来越层沉。这就要求我们的设计能让人乐于使用，也能很容易的适应改变。这就是柔性设计。* 模型的选择取决于3个基本的用途： 模型与设计核心的相互塑形、模型是所有团队成员所使用语言的核心、模型用来提炼知识* 知识消化并不是一个孤立的活动，它是由开发团队与领域专家共同合作，由开发人员领导的。知识消化过程必须探索模型选项，并将它们精化为使用的软件元素。* 那些没有领域模型，只是靠编写代码来完成一个又一个功能的项目，不能获得知识消化与交流带来的益处。* 领域模型的不断精化使得开发人员不断地学习他们的重要业务原理，而不是机械的产生新的功能。* 模型关注的是需求分析，它与编程和设计相互影响。* 重组会打散团队，知识也会再次分散。仅仅交付了代码而没有传递知识的工作方式使得一些关键的子系统无据可依。使用典型的设计方法时，代码和文档都不能用有效的方式表达出人们辛苦得到的知识，因此当这种口头上的惯例由于任何原因被打破时，知识也就遗失了。* 高效率的团队依靠学习，有意识的增长自己的知识，这意味着提高技术知识以及一般的领域建模技能，也包括学习所从事的特定领域。* 使用术语及关系来反映领域的内涵。基于模型的交流提高编写文档的实用性。* 要将模型作为语言的骨干。使用了通用语言，模型就不仅仅是一个设计工作了。它整合到开发人员与领域专家所做的每一件事中。* 一定要记住模型并不是图，图的目的是帮助表达和解释模型。* 说明性模型的图形带有它所表示模型的自然语言解释。一起查看两种图形（说明性模型和类图模型）要比单独查看任何一种更容易理解。* 一个缺乏设计基础概念的软件最多只能是一个能够做游泳的事情却不能清楚解释它的行为的机械装置。* 建模与编程的完全分离是不可行的。* 纯粹的分析模型甚至不能够达到其理解领域的主要目标，因为重要的发现往往出现在设计/实现过程中。模型驱动设计抛弃了分裂分析模型与设计的做法，而是寻找一个单独的模型来满足着两方面的要求。* 将分析、建模、设计和编码的职责完全隔离起来，会阻碍模型驱动设计。分开会造成：交接时遗漏了模型的一些意图；模型与实现和技术之间的相互作用个所得到的反馈过于间接。* 负责建模的技术人员必须花时间接触代码，而不论他是否在项目中担当主要角色。任何负责代码修改的人员都必须学习通过代码表达模型。每个开发人员都必须参与一些级别的模型讨论中，并与领域专家接触。* 解决来自领域方面的软件部分通常只占整个软件系统的一小部分，这与它的重要性相比是不成比例的。我们需要把领域对象跟系统的其他功能分离出来，才能够避免将领域概念与其他软件技术相关的概念混淆或者在系统的庞大中失去了对领域的把握。* 是领域层而不是应用层负责提供基本的规则。* 在应用一个框架是，开发团队应该首先明确它的目标：创建一个实现来表示一个领域模型并且用这个实现来解决重要的问题。* 不受限制的数据库查询实际上会破坏领域对象和聚合的封装。* 一般来说，不要与框架对着干。寻找合适的方法来保持领域驱动设计的基本方向。如果框架与设计发生矛盾的话，在一些细节问题上顺其自然。寻找领域驱动设计的概念与框架概念有哪些相近之处。当然，这里的假设是我们除了使用该框架之外别无选择。* 建模和设计不是一个匀速向前的过程，如果不频繁重构，利用新的理解来改进模型和设计，我们就会逐渐变的寸步难行。* 约束构成了模型概念中特别重要的一种类型。* 流程是应该被显示的描述出来还是应该隐藏起来？区分的要点很简单：这个流程是领域专家所谈论的流程，还是仅仅是计算机程序机制的一部分？

E文不行，看翻译的，看的吐血

Google翻译还是有道翻译的。。弄明白后想竖个中指，那么简单的概念，翻译的那么复杂。Google翻译还是有道翻译的。。弄明白后想竖个中指，那么简单的概念，翻译的那么复杂。

主要思想

不要过于关注书中描述的具体技术、设计方法领域模型贯穿概念模型、逻辑和物理设计模型，贯穿需求采集、分析、设计、实现，到测试部署这一整个开发过程，应该注意从整体角度来理解领域驱动的思想需求采集时与业务专家的沟通已经开始领域模型的建模工作；对需求深入的分析整理与业务专家探讨确认，目的是构造出扩展性比较好的弹性模型；设计模型与领域模型不要独立开来，尽量与领域模型保持比较高的匹配程度，不要让太多的设计细节扰乱领域模型的表达力；代码实现尽量将与领域逻辑无关的处理分离或独立开来，尽量让代码比较简洁、清晰的描述领域逻辑；后续的迭代是基于对领域逻辑深层次的理解来完善领域模型，向深度模型(deep model)发展；

value object 的不变性和代数的计算封闭性质

在书中提到 value object 具有不变性和代数的计算封闭的性质。在最近的几个开发项目中，大量地使用了 value object 。当使用 c/c++ 来开发的时候，使用 value object 可以减轻内存管理的负担。能带来这种便利的正是因为 value object 具有不变性。value object 一经构造就不能再改变其状态，可以说是强迫使用 value object 的代码为每种不同的目的声明不同的变量，而不是拿着一个 object，然后在不同的代码段中随需修改而用之，这样就造成了一个 object 被过度地引用，进而带来内存管理上的麻烦。

把咨询的事儿留给做咨询的人吧

这半年读了几本书，看了不少文章/网页，感谢这些书与文章让我能高屋建瓴看待这个行业，正确定位自己的职业，看清未来的方向。不过到此暂时打住，我想自己现在最需要的是技术积累，过完年要潜心于技术了。至于这本书，翻译的水平看过的人有自己的判断，如果你的公司或者项目觉得要实施DDD的话，最好还是找那些大牛们的咨询公司合作一下，而不是把书一看就自己搞起来了，当然，如果你自己也是大牛，那得除外。很多需要咨询公司的地方不要自己闭门造车，就像想吃某些菜要下馆子而不是自己做一样。

书不错，但翻译得不好

原版内容应该不错，但翻译得不好，这可能是国内技术类图书翻译的通病。以阅读翻译后的吃力劲，去看原版可能效果更好。也许是译者英文看多了，对汉语的语序也变得“英语化”了，有些简单的语言逻辑，被翻译之后，反而变得更生涩难懂。但愿那些从事翻译的人在精通计算机专业的同时，把汉语也能强化一下。用简单的语言表达复杂的意思，这才算是真正的译者。推荐阅读英文原版。

关于仓储（Repository)的设计

怎么样的仓储的设计，才能不至于让更多的业务逻辑跑到查询代码中？无限制的仓储使用，会使很多业务逻辑都嵌入到查询代码中，而不是通过领域对象之间的交互而取得，从而使数据库和业务逻辑纠缠到一起，又回到了数据库驱动的时代了。