《领域驱动设计》是一本由埃文斯著作，人民邮电出版社出版的平装图书，本书定价：69.00元，页数：369，特精心收集的读后感，希望对大家能有帮助。
《领域驱动设计》读后感(一)：很受用
目前正在做敏捷交付，这本书对敏捷方式的支持简直是完美对接来形容.欢迎广大程序猿认真仔细的阅读。
目前正在做敏捷交付，这本书对敏捷方式的支持简直是完美对接来形容.欢迎广大程序猿认真仔细的阅读。
目前正在做敏捷交付，这本书对敏捷方式的支持简直是完美对接来形容.欢迎广大程序猿认真仔细的阅读。
《领域驱动设计》读后感(二)：其实是一种方法论
很多年前读过，那时候没有懂。 现在再读，里面很多设计上的手法和模式已经成为常识，但其作为方法论的那部分历久而弥新，仍然极有价值。
我理解的主要思想包括：
一、创建共同语言： 领域专家和开发人员用同一种语言讨论问题。同一概念只有一个术语表达，一个术语准确表达一个概念。
二、模型驱动开发： 模型既设计、代码与设计一致。
为了达到第二个目的，用这种方法论做出的模型必须既能让领域专家看懂（因此需要屏蔽技术细节），又要能指导开发（因此必须包含有足够的软件设计要素），所以作者提出的建模方法没有规定建模的符号（UML不是必须的），但是规定了必须包含的一些组成要素。
1、架构
2、实体和值对象
3、关联和聚合以及repository
4、服务
总的来说，是一种非常实用的，自顶向下的设计方法。
《领域驱动设计》读后感(三)：书评：领域驱动设计
虽然实际读的好像是另一个出版商的，但是应该问题不大。 --- 先说结论：这本书给了我一个完全不一样的视角来关心一个复杂领域的结构设计、并且提供了一个切实可行的复杂模型来应对它并实现完美的关注点分离。 实际编码场景中，我们时常会遇到业务需求和编码实现的鸿沟。身为一名软件工程师，我们可能会更关心细节（比如说数据库、接口设计等），但是业务方会更关心庞大系统中这个部件的稳定可靠和满足需求。关心的点不同，导致我们很难交流，或者说提供的信息不同。 敏捷开发流程强调 mvp，强调与需求方的及时交流，这是战略。如何快速有效得获取一个一致的模型呢？本书费了一番笔墨讲解了通用语言的重要性，并且围绕着通用语言构建了足够抽象的领域模型 --- 很高兴我们和需求方能够有一个摒弃了实现细节而专注与需求本身的对象图。
围绕着我们的核心（领域层），我们开始将其实现落地，于是有了基础设施层、应用层和接口层。
（本书还包括了如何持续集成地进行迭代和突破，很重要，但是不是本书评的重点，略过，嘿嘿嘿嘿）
最后我们面向了一个企业级别的系统，如此复杂，以至于一个领域层构成的服务根本无法 hold 住。接下来作者缓缓道来了 bounded context 以及围绕着它的一系列基础措施。
哲学家说：“人是万物的尺度”，对于一个复杂软件系统而言又何不是这样呢？一个子系统如果无法让继任者在 15 分钟内理解，在某种意义上不就对于人而言过于庞大了吗，那它又怎样才能持续发展呢？
作者以一种缓缓道来的方式讲解复杂结构，不得不拍案叫绝。在微服务盛行的当下，我更是认为每一个从业者都可以读读这本书，了解以一个不一样的视角审视复杂系统、并合理处理系统的复杂度。
《领域驱动设计》读后感(四)：观点摘录
软件最有价值部分是它的领域模型部分。软件开发应该围绕这个核心进行组织，这是领域驱动设计的核心理念。
这本书有价值的地方甚多，值得反复细细揣摩，书中最重要观点，摘录如下：
1.软件开发复杂性的根本原因是问题领域本身错综复杂，控制复杂性的关键是有一个好的领域模型，此模型不应该仅仅停留在领域的表面，而是要透过表象抓住领域的实质结构，从而为软件开发人员提供他们所需的支持，
2.开发人员之间对话，领域专家之间讨论，以及代码本身表达，都应该基于同一种语言，来自一个共享的领域模型
3.不能把模型仅仅作为理解工具，而应该严格按基础模型编写代码。模型驱动设计寻求分析和设计的合一，程序设计，以至代码本身，都与模型密不可分。
4.由于领域模型的重要性，需要有意识的将领域对象与系统中其他对象分离，开发者借助各种各领域基础模型（实体「Entity」，值对象「Value Object」，服务「Service」，包「Package」等）以及各种领域对象生命周期管理策略（聚合「Aggregate」，工厂「Factory」，存储库「Repository」等）来消除模型和现实间的鸿沟
5.模型的构建不可能一步到位，真正强大的领域模型是随着时间演讲的，即使是最有经验的建模人员也往往发现他们是在系统的初始版本完成之后才有了最好的想法。－－理解的逐步深入，重构的必然与重构的方向
6.隐式概念的挖掘办法：倾听语言；检查不足之处；思考矛盾之处；查阅书籍；不要固执己见，尝试，再尝试！
7.可建模概念的种类：经常被领域专家提及的－－事物、行为、约束、过程。
8.模型构建的逐步深入导致重构不可避免，所以提倡柔性设计：设计必须要让人们乐于使用，并且易于做出修改。各种常用柔性设计模式。
9.如何在复杂系统，多团队下实现模型驱动目标的三大基本原则
上下文：子模型的边界及转换
精炼：关注对模型核心的持续提炼
大比例结构：总指导原则
《领域驱动设计》读后感(五)：《领域驱动设计》书评
首先说一下我是如何接触这本书的吧。我已经记不起是第一次听说领域驱动是在什么时候了，不过我只记得是在看一本别的架构方面的书时提及到这本书，我顺手在amazon上查了一下，有很多人在推荐这本书。出于对技术的追求，我有立刻把这本书买回家细细研读一下的冲动，于是我上网上书店找了一下，早已经卖断货了，在网上等了好长时间也没有补货上来，在着期间我还几乎走遍了我附近的各个书店，都没有找到。最终我从朋友的朋友那里借到了这本书。
真正读到后，我暗自庆幸当初苦苦寻觅这本书是一个多么正确的决定，在我现在看来这本书使我在学习对面向对象的路上少走了不少弯路。
因为是别人的书也就没有来的及读第二遍，现在终于拿到属于自己的书了，我迫不及待的又重读了这本书。
作者在书的组织上是由浅入深，并兼顾了对非领域模型的讨论，作者不仅仅讨论了自己设计的成功之处，也讨论了在多年的工作中遇到的一系列问题，以及如何用领域驱动的方式去挽救项目。
我们所开发的软件通常来说都并非是自己熟悉的行业，每个人都不自觉的会用自己的方式去理解软件的一个业务的服务流程。开发人员达成一致的流程往往不是客户真正实用的流程，这种不一致的情况可能会导致开发中反复的修改，更严重的可能会导致整个软件的架构都要发生重大的变化。这样会增加项目的开发时间增加项目的开发成本，如果这些条件不被允许，那么最终也就导致了项目的失败。
现在的软件开发过程理论都提倡和客户有足够的交流，确保开发出来的软件就是客户真正想要的。
领域驱动不是过程理论，但是它给出了具体的实践过程，兼顾领域专家和开发人员，两者达成一个共同的讨论模型，基于这个模型，软件设计人员或者开发人员能够根据自己对技术的理解，去设计合理的架构。这本书的作者给出了很多的建议来从模型讨论中提炼合理的架构，设计领域的对象模型，同时给出了一些常用的设计模式如何在领域层中应用的建议，并给出了领域层的边界（分清楚那个层应该干什么如何干，这个很重要）。
我们每天做的面向对象设计，其实就是在提炼类和划分类的职责。我们喜欢把这个过程称之为设计，如何能更好的的分析和提炼这是一门艺术。
我们每个人都可以做设计，在做的过程中谈不上这个过程的好坏，只有设计的结果我们才能有好坏之分。比如说我们每个人都可以下厨房做菜，做菜的过程谈不上好坏，但最终菜的味道就有好坏之分了。现实中如果我们想把菜做好，那么找一本厨艺大师的做菜心得的书读一下，一定会比我们瞎摸索要好的多。Eric Evans就是当之无愧领域模型设计界的厨艺大师，我们没有理由自己去瞎摸索来提高自己的“厨艺”。
【摘自】/cuiweifu/archive//12/09/book_review_for_Domain_Driven_Design.html
