解构领域驱动设计

前面道理讲的很清楚，系统组成部分相比整个系统是简单的，但是各部分之间相互作用，则产生了复杂系统。 所以让组成部分相对独立，有序协作，就直接会大大减少系统复杂度。 规模是影响理解力的关键要素，结构也对复杂度有着重要影响，这其实体现了架构设计的重要性。 DDD就是这样一个方法论，指导如何 合理的 划分组成部分边界，控制组成部分大小合适的规模 以及 它提供的能力，加上各部分之间的协作关系。 它关注的不仅仅是上层的结构设计，也关注污浊不堪的细节层面， 强调架构演进性，抵抗技术债。 事实就是这样，架构设计不只是大的结构上的，关注组成部分中具体的模型和关系同样关键。 系统之美中也有一句话， 一个系统中包含很多子系统，而它又存在于更大的系统中，这提示我们应以系统视角看待任何部分，系统就像是套娃，大系统小系统小小系统之间就像是在搭积木。 领域 子域 聚合 聚合内的模型 都是我们面对的“系统”，那么把每个“系统”处理到何种程度的规模，它们之间是何种协作、通信， 正是DDD所讲的。 最后各种思想都有它的局限性，辩证思考他们的优点和缺点，以及自己需要做到什么程度，太追求极致可能带来的又是边际成本递增。 架构设计的终点，是基于多种方法论和经验的辩证和平衡的艺术。 PS：推荐给的不只是这本书，更多的是DDD的思想，多年前还在上学时看Eric原著的时候看目录都看不懂，还在奢望读英文原版，最后看了几页 和 几篇文章，毛也没理解到。后来还花1500（可惜了….）元买了一个人的视频课，上来第一节就讲要如何写，现在回想真的可笑。 后来逐渐遇到一些复杂系统，才算是明白了一点，Eric和Vaughn解决的是什么问题。

感觉读一遍根本就没用，起码得三遍起。内容没的说，全部是干活，只不过需要一个特别煎熬的“啃”的过程，这也说明了领域驱动设计的学习取消是多麽陡峭。有决心有毅力的小伙伴百分之百推荐把这本书当作启蒙、提高以及应用当中的工具书。

粗略的翻看了一遍，总体感觉逻辑还是比较完整的，围绕着领域驱动设计统一过程进行阐述，知识比较多，内容比较广，融入了作者在软件系统架构方面的丰富经验，并且有理论有样例，实操性也比较好，在实践领域驱动设计时可以作为一本不错的参考书。

项目使用过领域驱动设计，但不知所以然。 本书虽然概念较多，但也有独到之处，选择性的阅读了一些内容，😁学到了东西。

有实操性，对领域驱动设计有了结构性了解。

废话连篇，DDD就能表达的内容，全篇“领域驱动设计”光这六个字估计得占了1w字。各种套用概念，使用“解空间”，想抽象包装的高大上一些，但反而觉得可笑，如果真的懂，就做的彻底点，把技术设计问题转化为数学上的优化问题，论证说明为什么领域设计方法，在这个优化问题上是一个合适的方法。能这么组织也可以，但除了套用概念没其它实用的内容

《解构领域驱动设计》这书强烈推荐，作者深入理解了领域驱动设计的原理，并直言不讳的指出领域驱动设计有四大不足：领域驱动设计缺乏规范的统一过程，领域驱动设计缺乏与之匹配的需求管理体系，领域驱动设计缺乏规范化的、具有指导意义的架构体系，领域驱动设计的领域建模方法缺乏固化的指导方法。在提出问题后，作者在领域驱动设计的基础上提炼出一套流程化、可落实的操作流程，让原本抽象的，依赖经验的领域驱动设计不再那么晦涩难懂，而是按照领域驱动设计统一过程，新手也有参考的步骤的范例，这样便于领域驱动设计的落地。 这是一本软件设计的书，但作者在写作时，并不单纯的局限于软件开发，在写作的过程中，尝尝提供了发散性思维，值得我们深思，作者的所表的思想并比仅仅适用软件开发，更多的事提供一种解决问题的方法论，一种对世间万物的理解的哲学之道。

读《解构领域驱动设计》，让我跳出对 DDD 概念的表层认知，真正理解领域驱动设计并非一堆模式的堆砌，而是一套面向复杂业务的思考方式。书中对战略设计、战术建模的拆解，理清了限界上下文、聚合、统一语言的内在联系，纠正了我把 DDD 简单等同于微服务的误区。 很多项目问题，根源不在于技术实现，而是业务理解不到位、边界划分模糊。这本书兼顾理论与落地，告诉我们建模要贴合真实业务，不能机械套用模板。结合日常开发，我意识到前期做好领域梳理，能够减少后期大量的业务返工。DDD 重在思维转变，后续工作中我会尝试用领域视角分析需求，平衡业务复杂度与技术实现。

25年阅读完的技术专业书，值得推荐。 本书深入浅出地介绍了领域驱动设计(ddd)，重点有三: 1.why？引入领域驱动设计的目的是为了降低业务复杂度和团队沟通成本。 2.what？领域驱动设计，是以业务为核心，通过构建具有业务逻辑的领域模型，以聚合，实体，值对象，消息契约，事件等关键节点，实现业务逻辑和技术逻辑分离的一种设计理念。 3.how?如何使用ddd，核心在于在项目实践中梳理出业务边界，隔离变与不变，使用充血模型替代贫血模型，等等，不一而足。 目前正在初步尝试ddd，同时也谨记不能过度设计，在探索一种适合自己的开发范式。 雷

之前也读过Eric的DDD，相较而言，这本书在对DDD的精细度和落地指导上做得更为具体和系统。提出了“领域驱动设计统一过程”来指导DDD的具体实践。 不过，书中也提到DDD是为了控制软件复杂度，但我感觉这套体系本身似乎也够复杂了（结合书中对复杂度的定义：规模、结构、变化）。有几个问题可惜没有看到解答：是不是张逸这套方法论本质上将原本代码实现中的复杂度转移到了分析与设计阶段？如果真是这样，那么这种复杂度转移是否真的有意义？设计和分析的复杂度是否应该取代或优先于代码实现的复杂度？如果存在DDD的使用范围，那这个范围的尺度是多大呢？