首先说一下我是如何接触这本书的吧。我已经记不起是第一次听说领域驱动是在什么时候了，不过我只记得是在看一本别的架构方面的书时提及到这本书，我顺手在amazon上查了一下，有很多人在推荐这本书。出于对技术的追求，我有立刻把这本书买回家细细研读一下的冲动，于是我上网上书店找了一下，早已经卖断货了，在网上等了好长时间也没有补货上来，在着期间我还几乎走遍了我附近的各个书店，都没有找到。最终我从朋友的朋友那里借到了这本书。
真正读到后，我暗自庆幸当初苦苦寻觅这本书是一个多么正确的决定，在我现在看来这本书使我在学习对面向对象的路上少走了不少弯路。
因为是别人的书也就没有来的及读第二遍，现在终于拿到属于自己的书了，我迫不及待的又重读了这本书。
作者在书的组织上是由浅入深，并兼顾了对非领域模型的讨论，作者不仅仅讨论了自己设计的成功之处，也讨论了在多年的工作中遇到的一系列问题，以及如何用领域驱动的方式去挽救项目。
我们所开发的软件通常来说都并非是自己熟悉的行业，每个人都不自觉的会用自己的方式去理解软件的一个业务的服务流程。开发人员达成一致的流程往往不是客户真正实用的流程，这种不一致的情况可能会导致开发中反复的修改，更严重的可能会导致整个软件的架构都要发生重大的变化。这样会增加项目的开发时间增加项目的开发成本，如果这些条件不被允许，那么最终也就导致了项目的失败。
现在的软件开发过程理论都提倡和客户有足够的交流，确保开发出来的软件就是客户真正想要的。
领域驱动不是过程理论，但是它给出了具体的实践过程，兼顾领域专家和开发人员，两者达成一个共同的讨论模型，基于这个模型，软件设计人员或者开发人员能够根据自己对技术的理解，去设计合理的架构。这本书的作者给出了很多的建议来从模型讨论中提炼合理的架构，设计领域的对象模型，同时给出了一些常用的设计模式如何在领域层中应用的建议，并给出了领域层的边界（分清楚那个层应该干什么如何干，这个很重要）。
我们每天做的面向对象设计，其实就是在提炼类和划分类的职责。我们喜欢把这个过程称之为设计，如何能更好的的分析和提炼这是一门艺术。
我们每个人都可以做设计，在做的过程中谈不上这个过程的好坏，只有设计的结果我们才能有好坏之分。比如说我们每个人都可以下厨房做菜，做菜的过程谈不上好坏，但最终菜的味道就有好坏之分了。现实中如果我们想把菜做好，那么找一本厨艺大师的做菜心得的书读一下，一定会比我们瞎摸索要好的多。Eric Evans就是当之无愧领域模型设计界的厨艺大师，我们没有理由自己去瞎摸索来提高自己的“厨艺”。