自2003年Eric Evans的著作《领域驱动设计》面世以来， 领域驱动设计（DDD） 相关的实践书籍并不多，整体的理论发展速度并不快，以至于很长一段时间，开发团队的实践过程总是磕磕绊绊， 这让他们觉得领域驱动设计的门槛很高，甚至有人怀疑领域驱动设计是否是一种足够成熟与体系化的方法论。
学习领域驱动设计有这两本书，一切将不再是
所谓“解构”，就是解析与重构：
本书不再满足于粗略地将内容划分为战略篇和战术篇， 而是在领域驱动设计统一过程的指导下， 将该过程的3个阶段——全局 分析、架构映射和领域建模作为本书的3个核心篇，再辅以开篇和融合，共分为5篇（20章）和4个 附录，全面而完整地表达了我对领域驱动设计的全部认知与最佳实践。在对内容做进一步精简后， 本书仍然接近600页，算得上是软件技术类别的大部头了。
该如何阅读这样一本厚书呢？
若你时间足够充裕，又渴望彻底探索领域驱动设计的全貌， 我建议还是按部就班、循序渐进 地进行阅读。或许在阅读开篇的3章时，你会因为太多信息的一次性涌入而产生迷惑、困扰和不解， 这只是因为我期望率先为读者呈现领域驱动设计的整体面貌。在获得领域驱动设计的全貌之后，哪 怕你只是在脑海中存留了一个朦胧的轮廓，也足以开启自己对设计细节的理解和认识。
若你追求高效阅读，又渴望寻求领域驱动设计问题的答案，可以根据目录精准定位你最为关心的技术讲解。或许你会失望，甚至产生质疑，从目录中你获得了太多全新的概念， 而这些概念从未见于任何一本领域驱动设计的图书，这是因为这些概念都是作者针对领域驱动设计提出的改进与补充， 是作者解构全新领域驱动设计知识体系的得意之笔——要不然，一本技术图书怎么会写三年之久呢？
作者将自鸣得意的开创性概念一一罗列于此。
业务服务。业务服务是全局分析的基本业务单元，在统一语言的指导下完成对业务需求的 抽象，既可帮助我们识别限界上下文，又可帮助开发团队开展领域分析建模、领域设计建 模和领域实现建模。业务服务的粒度也是服务契约的粒度，由此拉近了需求分析与软件设 计的距离，甚至可以说跨越了需求分析与软件设计的鸿沟。
菱形对称架构。虽然菱形对称架构脱胎于六边形架构与整洁架构，但它更为简洁， 与限界 上下文的搭配可谓珠联璧合，既保证了限界上下文作为基本架构单元的自治性，又融入了 上下文映射的通信模式，极大地丰富了设计要素的角色构造型。
服务驱动设计。服务驱动设计采用过程式的设计思维， 却又遵循面向对象的职责分配， 能 在提高设计质量的同时降低开发团队的设计门槛，完成从领域分析模型到领域实现模型的 无缝转换，并可作为测试驱动开发的前奏，让领域逻辑的实现变得更加稳健而高效。
以上概念皆为领域驱动设计统一过程的设计元素， 又都能与领域驱动设计的固有模式有机融 合。对软件复杂度成因的剖析，对价值需求和业务需求的划分，在领域驱动设计统一过程基础上建 立的能力评估模型与参考过程模型，
本书终于实现了一个宏伟抱负，即描述并建立了领域建模艺术的词汇库。它提供了一个参考框架，人们可以用它来解释相关活动，并用它来传授这门难学的技艺。
你可以学到的两大经验
首先，在领域建模过程中不应将概念与实现割裂开来。高效的领域建模人员不仅应该能够在白板上与会计师进行讨论，而且还应该能与程序员一道编写Java代码。之所以要具备这些能力，一部分原因是如果不考虑实现问题就无法构建出有用的概念模型。但概念与实现密不可分的最主要原因在于，领域模型的最大价值是它提供了一种通用语言，这种语言是将领域专家和技术人员联系在一起的纽带。
我们将从本书中学到的另一个经验是领域模型并不是按照“先建模，后实现”这个次序来工作的。
复杂性的挑战
很多因素可能会导致项目偏离轨道，如官僚主义、目标不清、资源缺乏等。但真正决定软件复杂性的是设计方法。当复杂性失去控制时，开发人员就无法很好地理解软件，因此无法轻易、安全地更改和扩展它。而好的设计则可以为开发复杂特性创造更多机会。
一些设计因素是技术上的。软件的网络、数据库和其他技术方面的设计耗费了人们大量的精力。很多书籍都介绍过如何解决这些问题。大批开发人员很注意培养自己的技能，并紧跟每一次技术进步。
然而很多应用程序最主要的复杂性并不在技术上，而是来自领域本身、用户的活动或业务。当这种领域复杂性在设计中没有得到解决时，基础技术的构思再好也无济于事。成功的设计必须系统地考虑软件的这个核心方面。
本书有两个前提：
（1）在大多数软件项目中，主要的焦点应该是领域和领域逻辑；
（2）复杂的领域设计应该基于模型。
领域驱动设计是一种思维方式，也是一组优先任务，它旨在加速那些必须处理复杂领域的软件项目的开发。为了实现这个目标，本书给出了一整套完整的设计实践、技术和原则。
设计过程与开发过程
设计书就是讲设计，过程书只是讲过程。它们之间很少互相参考。设计和过程本身就是两个足够复杂的主题。本书是一本设计书，但我相信设计与过程这二者是密不可分的。设计思想必须被成功实现，否则它们就只是纸上谈兵。
当人们学习设计技术时，各种可能性令他们兴奋不已，然而真实项目的错综复杂又会为他们泼上一盆冷水。他们无法用所使用的技术来贯彻新的设计思想，或者不知道何时应该为了节省时间而放弃某个设计方面，何时又应该坚持不懈直至找到一个干净利落的解决方案。开发人员可以抽象地讨论设计原则的应用，而且他们也确实在进行着这样的讨论，但更自然的做法应该是讨论如何完成实际工作。因此，虽然本书是一本有关设计的书，但我会在必要的时候穿越这条人为设置的边界，进入过程的领域。这有助于将设计原则放到一个适当的语境下进行讨论。
虽然本书并不局限于某一种特定的方法，但主要还是面向“敏捷开发过程”这一新体系。特别地，本书假定项目必须遵循两个开发实践，要想应用书中所讲的方法，必须先了解这两个实践。
（1）迭代开发。人们倡导和实践迭代开发已经有几十年时间了，而且它是敏捷开发方法的基础。在敏捷开发和极限编程（XP）的文献中有很多关于迭代开发的精彩讨论，其中包括Surviving Object-Oriented Projects [Cockburn 1998] ①和Extreme Programming Explained [Beck 1999]。
（2）开发人员与领域专家具有密切的关系。领域驱动设计的实质就是消化吸收大量知识，最后产生一个反映深层次领域知识并聚焦于关键概念的模型。这是领域专家与开发人员的协作过程，领域专家精通领域知识，而开发人员知道如何构建软件。由于开发过程是迭代式的，因此这种协作必须贯穿整个项目的生命周期。
本书将设计和开发实践结合起来讨论，并阐述领域驱动设计与敏捷开发过程是如何互相增强的。在敏捷开发过程中使用成熟的领域建模方法可以加速开发。过程与领域开发之间的相互关系使得这种方法比任何“纯粹”真空式的设计更加实用。
