《领域驱动设计》读后感精选

　　《领域驱动设计》是一本由[美] Eric Evans著作，人民邮电出版社出版的平装图书，本书定价：69，页数：370，特精心从网络上整理的一些读者的读后感，希望对大家能有帮助。

　　《领域驱动设计》读后感(一)：又是一本能让自己产生质变的好书

　　该书作者显然拥有大量的设计、编码实践。而且看的出，还是敏捷的拥护者。

　　难能可贵的是，该书的翻译质量还是很高的。很多地方直接使用英文原文，而不是搞个蹩脚的中文翻译来打乱你的阅读节奏。

　　只是有部分举例可能因为需要具有业务背景知识才好理解，所以自己感觉没能特别掌握作者要表达的深层含义。

　　《领域驱动设计》读后感(二)：不推荐任何高手以及新手阅读

　　10年前的东西了再次印刷来骗钱, 写的很拗口, 很简单的概念有大量篇幅描述, 完全是耽误码农宝贵的时间, 我花了3个小时读完了, 走马观花了下对于一个工作了10年的开发者来说没有任何帮助, 我相信10年前如果我读, 也不会有任何帮助, 所有人都可以看看自己目前工作中是否有人使用DDD, 各类问答网站中是否热烈讨论DDD, 答案是完全没有, 还是按照Controller > Service > Dao吧, 时代变了, 软件开发的理念也都变了

　　《领域驱动设计》读后感(三)：挺好的，道术结合的一本书

　　我是一个所谓前端er，但我觉得对领域的概念对所谓的前端er们而言也非常重要。特别是中后台的业务前端在不需要实现界面操作的前提下，了解业务的实现非常重要。

　　这本书里讲了很多的"道"，例如团队协作，开发人员对待需求的态度。

　　我觉得这本书适合想要了解业务实现的开发人员，项目经理以及产品经理阅读。不懂的技术点可以模糊的过去。

　　所以，这本书适合入门，那本红色的领域驱动设计其实太偏重"术"了。

　　《领域驱动设计》读后感(四)：挺好的，道术结合的一本书

　　我是一个所谓前端er，但我觉得对领域的概念对所谓的前端er们而言也非常重要。特别是中后台的业务前端在不需要实现界面操作的前提下，了解业务的实现非常重要。

　　这本书里讲了很多的"道"，例如团队协作，开发人员对待需求的态度。

　　我觉得这本书适合想要了解业务实现的开发人员，项目经理以及产品经理阅读。不懂的技术点可以模糊的过去。

　　所以，这本书适合入门，那本红色的领域驱动设计其实太偏重"术"了。

　　《领域驱动设计》读后感(五)：挺好的，道术结合的一本书

　　我是一个所谓前端er，但我觉得对领域的概念对所谓的前端er们而言也非常重要。特别是中后台的业务前端在不需要实现界面操作的前提下，了解业务的实现非常重要。

　　这本书里讲了很多的"道"，例如团队协作，开发人员对待需求的态度。

　　我觉得这本书适合想要了解业务实现的开发人员，项目经理以及产品经理阅读。不懂的技术点可以模糊的过去。

　　所以，这本书适合入门，那本红色的领域驱动设计其实太偏重"术"了。

　　《领域驱动设计》读后感(六)：也并不是那么值得一读吧

　　刚开始是冲着这个书的副标题来的，软件核心复杂性应对之道，主标题并没有太在意。最后看了不到一半吧，零散着跳读的。翻译问题很大！！！

　　进书便开始和我说模型的事，又是分层又是画图，看了几章发现，弄了半天不就是一个UML图吗。

　　这书给我感觉是一本教 不懂业务只懂编程的程序员 和 不懂编程只懂业务的业务专家 如何交流的书，但我感觉是不是翻译的问题，这书中介绍的东西更像是每个人都会做的意义。

　　给一个团队放一个业务领域的专家，大家彼此磨合几天，这书好像也就没那么值得一读了。

　　《领域驱动设计》读后感(七)：技术过时，但思维不会

　　原版四星，中文版三星，知识有些陈旧、翻译差、阅读耗时、收益不成比率。

　　此书翻译比较差，一般情况是不符合中文的表达习惯，很多句子要读几遍才能明白，翻译差点的段落连机器翻译的质量都达不到。由于翻译质量差，所以可能需要花双倍以上的时间来阅读这本书，很多时候都会纠结是否值得继续读下去。

　　本书成书年代比较久远，作者当时的思维受限于当时的技术背景，但是在10多年前能有如此如此的思维已然是超级牛X的人物了。从目前的业务场景以及软硬件技术水平来看，书中很多具体的建议、模式都不太适用了，生搬硬套有百害而无一利，另外想要完全按照书中的领域驱动设计思想来进行软件开发，对于团队的要求其实还是挺高的，中国软件行业有自身的特点，很难满足领域驱动团队的需求，人员编码能力、业务分析能力、团队齐备性、人员稳定性、项目进度、公司发展都会成为领域模型的杀手；最后，个人觉得领域驱动设计如果用来编写代码其实是反人类的，有大量的最佳实践，有大量的领域简化规则，何必呢，选择一个标准，一个规范，然后又打破它，放弃它。一万个人心中有一万个哈姆雷特，何种开发方式能够适合10个人的团队是一个值得考虑的问题。所以就导致中间好多年领域驱动设计一致不太被大众接受，甚至后来到了无人问津的地步。而后随着微服务架构的兴起，需要对服务进行切分，而切分的首要因素就是按照业务进行切分，大家的视野又更多的投向了领域这个核心的概念，进而这本书又变成了一本畅销书了，周边很多都是读过或者在读这本书，大家的感受各不相同，有些觉得领域驱动设计是神器，就应该按照这种方式来进行架构和抽象，并完全按照这种方式来进行项目开发，另外一些则觉得书已然过时，只能学习其思想，而不是全盘接收，我的看法更多偏向于后者。

　　领域驱动的核心其实就是抽象、分层、分治、演进（这四个词是一个大佬总结的，我这里借用而已），书中的各种模式、各种技巧、各种案例也基本上都体现的都是这四种思维模式，所以阅读本书就当是架构思维的训练与演练，分析其模式的动机、面临的问题、解决问题的方式等等。这样就会收获很多。

　　《领域驱动设计》读后感(八)：方法论岂是那么好懂的

　　如果没有两年的编程经验，如果对设计一个新项目的逻辑分层、包结构没有疑问，那么就别看这书了...看不懂的。

　　本书讲的是一种应对复杂软件系统设计的思想，作者若没个十几年的编程功底，沉淀不了这种方法论，写不出这种书。

　　光看一遍是看不懂的，摘录一些点慢慢消化吧。

　　大多数成功的架构使用这种分层架构：

　　用户界面层（或表示层）：负责向用户（或计算机系统）显示信息和解释用户指令 应用层：定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，而只为下一层中的领域对象协调任务、分配工作，使它们互相协作，它没有反映业务情况的状态，但是却可以具有另外一种状态，为用户或程序显示某个任务的进度。 领域层（或模型层）：负责表达业务概念、业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层事先的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心。 基础设施层：为上面各层提供通用的技术能力，为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件等等。

　　给复杂的应用程序划分层次，在每一层内分别进行设计，使其具有内聚性并且只依赖于它的下层。采用标准的架构模式，只与上层进行松散的耦合。将所有与领域模型相关的代码放在一个层中，并把它与用户界面层、应用层以及基础设施层的代码分开。领域对象应该将重点放在如何表达领域模型上，而不需要考虑自己的显示和存储问题，也无需管理应用任务等内容。这使得模型的含义足够丰富，结构足够清晰，可以捕捉到基本的业务知识，并有效的使用这些知识。

　　Entity

　　实体的概念是一种贯穿整个生命周期（甚至会经历多种形式）的抽象的连续性。

　　一些对象主要不是由它们的属性定义的。它们实际上表示了一条“标识线”（A Thread of Identity），这条线跨越时间，而且常常经历多种不通的表示。

　　主要由标识定义的对象叫Entity。Entity（实体）有特殊的建模和设计思路，它们具有生命周期，这期间它们的形式和内容可能发生根本该表，但必须保持一种内在的连续性。为了有效地追踪这些对象，必须定义它们的标识。它们的类定义、职责、属性和关联必须由其标识来决定，而不依赖于其所具有的属性。Entity可以是任何事物，只要满足两个条件，一是它在整个生命周期中具有连续性，二是它的区别并不是由那些对用户非常重要的属性决定的。

　　Value Object

　　用于描述领域的某个方面而本身没有概念标识的对象称为Value Object（值对象）。Value Object应该是不可变的，被实例化之后用来表示一些设计元素，我们只关心它是什么，而不关心它是谁。Value Object经常作为参数在对象之间传递消息，它常常是临时对象，在一次操作中被创建，然后丢弃。

　　《领域驱动设计》读后感(九)：方法论岂是那么好懂的

　　如果没有两年的编程经验，如果对设计一个新项目的逻辑分层、包结构没有疑问，那么就别看这书了...看不懂的。

　　本书讲的是一种应对复杂软件系统设计的思想，作者若没个十几年的编程功底，沉淀不了这种方法论，写不出这种书。

　　光看一遍是看不懂的，摘录一些点慢慢消化吧。

　　大多数成功的架构使用这种分层架构： 用户界面层（或表示层）：负责向用户（或计算机系统）显示信息和解释用户指令 应用层：定义软件要完成的任务，并且指挥表达领域概念的对象来解决问题。这一层所负责的工作对业务来说意义重大，也是与其他系统的应用层进行交互的必要渠道。应用层要尽量简单，不包含业务规则或者知识，而只为下一层中的领域对象协调任务、分配工作，使它们互相协作，它没有反映业务情况的状态，但是却可以具有另外一种状态，为用户或程序显示某个任务的进度。 领域层（或模型层）：负责表达业务概念、业务状态信息以及业务规则。尽管保存业务状态的技术细节是由基础设施层事先的，但是反映业务情况的状态是由本层控制并且使用的。领域层是业务软件的核心。 基础设施层：为上面各层提供通用的技术能力，为应用层传递消息，为领域层提供持久化机制，为用户界面层绘制屏幕组件等等。

　　给复杂的应用程序划分层次，在每一层内分别进行设计，使其具有内聚性并且只依赖于它的下层。采用标准的架构模式，只与上层进行松散的耦合。将所有与领域模型相关的代码放在一个层中，并把它与用户界面层、应用层以及基础设施层的代码分开。领域对象应该将重点放在如何表达领域模型上，而不需要考虑自己的显示和存储问题，也无需管理应用任务等内容。这使得模型的含义足够丰富，结构足够清晰，可以捕捉到基本的业务知识，并有效的使用这些知识。

　　Entity 实体的概念是一种贯穿整个生命周期（甚至会经历多种形式）的抽象的连续性。 一些对象主要不是由它们的属性定义的。它们实际上表示了一条“标识线”（A Thread of Identity），这条线跨越时间，而且常常经历多种不通的表示。 主要由标识定义的对象叫Entity。Entity（实体）有特殊的建模和设计思路，它们具有生命周期，这期间它们的形式和内容可能发生根本该表，但必须保持一种内在的连续性。为了有效地追踪这些对象，必须定义它们的标识。它们的类定义、职责、属性和关联必须由其标识来决定，而不依赖于其所具有的属性。Entity可以是任何事物，只要满足两个条件，一是它在整个生命周期中具有连续性，二是它的区别并不是由那些对用户非常重要的属性决定的。

　　Value Object 用于描述领域的某个方面而本身没有概念标识的对象称为Value Object（值对象）。Value Object应该是不可变的，被实例化之后用来表示一些设计元素，我们只关心它是什么，而不关心它是谁。Value Object经常作为参数在对象之间传递消息，它常常是临时对象，在一次操作中被创建，然后丢弃。

　　《领域驱动设计》读后感(十)：看懂这本书你要先从真正理解名字开始！

　　看了对于此书的短评，把这本书看成是一本“正确的废话”的人我想不在少数，10年前我看此书也是一样的感觉，10年后微服务大火，很多人又把“领域驱动设计”挂在嘴边，此时我再看此书确实感觉自己看懂了，我想这其中的奥秘其实就在“领域驱动设计”这六个字里。让我给大家仔细分解一下。

　　首先要解释的是“设计”这个词，这个“设计”不是我们脑子里一般泛指的设计，而是指传统软件建模中的一个阶段，传统的建模理论把软件的开发分为4个阶段，分别是“业务建模”、“需求”、“分析”和“设计”。我们来看看《UML模式和应用》中对分析和设计的定义。

分析（analysis）强调的是对问题和需求的调查研究，而不是解决方案设计（design）强调的是满足需求的概念上的解决方案（在软件和硬件方面），而不是其实现。有益的分析和设计可以概括为：做正确地事（分析）和正确地做事（设计）

　　上面三句话已经很清楚的解释了“分析”和“设计”这两个词的意思，所以“分析”阶段产生的模型就叫做“分析模型“，而“设计”阶段产生的模型也就是“设计模型“。同理，所谓的“分析模式”和“设计模式”的意思也就清楚了。

　　解析了“设计”的含义，我们再看“领域”的含义，所谓“领域”就是“领域模型”，那么什么是领域模型呢？我们先看“传统的”面向对象分析和设计理论中的“领域模型”的定义，来自《UML模式和应用》第三版P100、P101中的话：

领域模型（domain model）是对领域内的概念类或现实世界中对象的可视化表示。领域模型也称为概念模型、领域对象模型、分析对象模型。在对象建模中，我们总会提到关于软件对象的职责，并且方法是纯软件概念。但是，领域模型描述的是真实世界的概念，而非软件对象的概念，对象职责在设计工作过程中非常重要，但它完全不属于领域模型。

　　第一段的重点在于“领域模型”是“分析”阶段产生的，所以也叫“分析对象模型”，第二段的重点在于对象的职责是属于“设计”的，不属于“分析”阶段的对象职责自然就不属于领域模型，是不是有点颠覆“三观”？

　　那么什么是Eric Evans心中的“领域模型”呢？

很多设计方法都提倡使用完全脱离于程序设计的分析模型, 并且通常这二者是由不同的人员开发的。之所以称其为分析模型,是因为它是对业务领域进行分析的结果,它在组织业务领域中的概念时,完全不去考虑自己在软件系统中将会起到的作用。分析模型仅仅是理解工具,人们认为把它与程序实现联系在一起无异于搅浑一池清水。 随后的程序设计与分析模型之间可能仅仅保持一种松散的对应关系。 在创建分析模型时并没有考虑程序设计的问题, 因此分析模型很有可能无法满足程序设计的需求。纯粹的分析模型甚至在实现理解领域这一主要目的方面也捉襟见肘, 因为在程序设计和实现过程中总是会发现一些关键的知识点, 而细节问题则会出人意料地层出不穷。 前期模型可能会深入研究一些不相关的问题, 反而忽略了一些重要的方面。 而且它对于其他问题的描述也可能对应用程序没有任何帮助。最后的结果就是:编码工作一开始,纯粹的分析模型就被抛到一边,大部分的模型都需要重新设计。即便是重新设计,如果开发人员认为分析与程序开发毫不相关,那么建模过程就不会那么规范。 而如果项目经理也这么认为, 那么开发团队可能没有足够的机会与领域专家进行交流。领域中还有一些方面适合用动作或操作来表示, 这比用对象表示更加清楚。 这些方面最好用SERVICE来表示,而不应把操作的责任强加到ENTITY或VALUE OBJECT上,尽管这样做稍微违背了面向对象的建模传统。

　　这三段话分别来自本书的P31和P51，我们先来看第一和第二段话，作者指出了“分析”和“设计”的脱节这个面向对象分析和设计方法论的致命问题，作者描述的这些问题我想有经验的开发人员因该都是深有体会的。第三段的话很关键也最不好懂，作者认为一个好的“领域模型”应该是“分析”和“设计”不脱节的，既能够包含“分析”阶段产生的对象（Entity、ValueObject）也能够包含表示动作或操作的“Service”，虽然这样和传统的面向对象建模相违背（为什么会违背我想你现在应该已经清楚了）

　　然后我们再来看Eric Evans定义的“领域模型”到底是什么有那些特征。

如果整个程序设计或者其核心部分没有与领域模型相对应,那么这个模型就是没有价值的, 软件的正确性也值得怀疑。同时,模型和设计功能之间过于复杂的对应关系也是难于理解的,在实际项目中,当设计改变时也无法维护这种关系。若分析与和设计之间产生严重分歧,那么在分析和设计活动中所获得的知识就无法彼此共享。在MODEL-DRIVEN DESIGN中, 代码是模型的表达, 改变某段代码就改变了相应的模型。任何参与建模的技术人员, 不管在项目中的主要职责是什么, 都必须花时间了解代码。 任何负责修改代码的人员则必须学会用代码来表达模型。

　　这三段话分别来自本书的P31和P40，重点说明了带有操作的“领域模型”和“设计”还有代码之间的关系，作者认为这三者因该相互紧密结合，因为“领域模型”融合“分析”和“设计”而“设计”本来就是指导编码的，所以编码和模型应该某种程度上“二合一”，来点题外话在这里Eric并没有明确说如何达到“二合一”的效果，但是要想达到“二合一”的效果，只有两条路，第一种就是“模型即是代码”，这就是为什么有些建模工具都能生成代码的原因，但是这条路正如大家看到的并不好走，所以更“现实”的方法就是“代码即是模型”，这就对代码的要求相当的高了，当然Eric也说了分析和设计的人员应该花时间了解代码，而全书后面的部分也就是各种“模式”也是在教你怎么写出“代码即是模型”。

　　好了，最后让我们看“驱动”二字，我先问一个问题“测试驱动开发”里，是先有测试还是先有开发？两者都不对，所谓“驱动”是两者交替相互成长的意思，“领域驱动设计”中的驱动也是如此，不是让你先有模型再有代码，写代码的过程中模型就完全不改了。也不是一定要先设计一个“完美”的模型，而是相互“驱动”，模型的改动会反应的在代码上，而代码的改动也将更好的帮助模型完善。

　　总结一下，所谓的“领域驱动设计”，说的是“领域模型”驱动设计，其中的领域模型和传统的面向对象分析设计的方法论不同，其中不但包含了“领域实体”还包含“领域服务”，这种模型和代码相互驱动达到了代码即是模型的效果，解决了传统OO理论中分析和设计相互脱节的问题，所以“DDD”也被称为OO的进阶”道理就在于此。

　　好了，希望这篇书评能够让你入门“DDD”，达到抛砖引玉的效果，谢谢耐心观看。