我正在撰写《实践领域驱动设计（Practice Domain-Driven Design，暂定名）》，本书的简略版会在近几个月陆续在GitChat上发布，而完整版会充实更多内容，然后出版纸质书。
最近十年，我在许多项目以及咨询中都在尝试实践领域驱动设计，也体会到这种设计方法给设计质量带来的好处。当然，领域驱动设计确乎博大精深，越要尝试去掌握它，就越发发现它的深邃。
在进行领域驱动设计咨询和培训过程中，我深刻体会到领域驱动设计的难以落地。即使是DDD的专家，也未必能非常轻易地给初学者讲清楚如何进行领域建模，如何改进领域设计的质量。专家们当然可以设计得很好，可一旦问他们为何要这样设计，他们或许会说“by experience”；但这真不是他们的故弄玄虚，而是真实感受，因为很多设计idea其实都是只可意会不可言传的。
然而在这些项目设计、咨询与培训过程中，因为碰到这样的理解障碍，我反倒是能够设身处地地从初学者角度去思考问题，并尝试给出一些所谓的“技巧”。我当然没法达到Eric Evans的高度，内容也没法超出经典著作《领域驱动设计》的范围，但自我感觉还是有一些属于自己独到的东西，这是我写书的底气。
从2007年出版《软件设计精要与模式》第一版，2009年出版《软件设计精要与模式》第二版之后，近10年的时间，我没有写书，只是翻译了好几本书。这期间也曾有计划继续写与软件设计有关的书籍，也准备了不少资料。因为想写好，反而有些不敢写，拖拖踏踏至今。这些写作计划以及准备的资料仍然在我的笔记中，以后会争取做到完成写作。
还是回到我计划写的这本书。内容上确实参考了DDD社区的好几本经典著作，但结合了我自身的经验和心得体会，因此写到书上，可以说多数都变成了自己的内容。我不知道最后的质量会如何，但我可以自信说，这是我自己的领域驱动设计作品。顺利地话，若能在今年完成，或许能成为国内第一本讲解领域驱动设计的书籍。
以下是目录：
- 第一章 领域驱动设计概览：整体介绍领域驱动设计的过程，并从软件复杂度的角度讲解领域驱动设计的价值。
- 第二章 提炼领域知识：团队与领域专家的沟通与协作，利用统一语言提炼领域知识，并引入场景驱动设计以及用例、行为驱动设计等方法帮助我们提炼领域知识。
- 第三章 限界上下文的实践意义：剖析限界上下文的本质，认识限界上下文的价值，并给出识别限界上下文的过程与方法。
- 第四章 限界上下文的协作与集成：深入剖析限界上下文之间的协作与集成模式，并为后面讲解微服务奠定基础。同时，基于Context Map重构前面识别的限界上下文。
- 第五章 运用限界上下文：给出识别和运用限界上下文的实际案例。在这一章中，会使用第三章和第四章介绍的方法与过程，对实际案例进行分析。
- 第六章 核心领域与子领域：从边界来看，限界上下文的粒度应该比module粗，但是从领域识别的角度来看，可能存在多个限界上下文属于同一个领域的情况。因而在领域驱动设计中，有必要引入一个更粗粒度的概念——核心领域与子领域。领域的划分是基于高内聚松耦合原则，从业务角度进行划分的。
- 第七章 运用设计原则重新规划架构层次：领域驱动设计的分层架构，六边形架构以及Uncle Bob提出的Clean Architecture都从架构层面是对领域驱动设计的补充。如何让这些模式与思想产生指导作用？我们需要结合在普适性的设计原则来重新审视它们。
- 第八章 领域驱动设计与微服务设计：限界上下文、核心领域、子领域，这些概念与微服务存在一定的映射关系。这也是领域驱动设计在架构模式中的价值所在。本章会结合微服务设计的角度，进一步阐释这些概念。
- 第九章 浮现领域模型：在限界上下文边界内，基于统一语言对领域进行建模。会介绍常用的建模方法，包括四色建模。
- 第十章 领域模型与编程范式：领域模型与程序设计存在指导与共同演进的关系。对领域进行建模实则就是DDD提出的模型驱动设计。如何建立模型，与选择的编程范式有关。主流的领域驱动设计以面向对象设计为主，但函数式编程思想也颇值得借鉴。
- 第十一章 表达领域模型：如何利用Entity、Value Object以及Service等构造块来表达领域模型。
- 第十二章 高质量地设计聚合：聚合在领域驱动设计中是一个相对棘手的概念。本章会给出设计聚合的原则与实践。
- 第十三章 领域对象的生命周期：运用工厂和Repository管理领域对象的生命周期。
- 第十四章 运用领域模型：讲解如何运用领域模型进行程序设计的案例，其中会运用到常用的设计模式、时序图等方法。
- 第十五章 事件驱动架构对模型的影响：以事件为设计驱动力在建模上存在不同的设计理念。以事件为驱动力，又会与Event Storming、Event Sourcing以及CQRS结合起来。本章会重点讲解event。
- 第十六章 战略设计与战术设计的融合：从战略设计到战术设计，并非一个单向的自顶向下的过程，而是螺旋式的迭代过程。当设计进入到战术阶段后，经过程序设计到编程实现，可能会发现隐藏的概念，也可能发现之前识别的限界上下文存在偏差，因而需要对前面的设计进行重构。