领域驱动设计（DDD）读书吐槽小记

DDD（Domain-driven Design）领域驱动设计是我今年读的第一本书，400来页的小册子，知识密集度和增量相比DDIA来说少了不少，一周的空闲时间足以读完。

附上书籍高清中文版PDF链接：https://pan.baidu.com/s/1BICFmIlsmgFBqK4OMO-G6A?pwd=iy5f

看完书多半是迷惑的，有必要看一下别人的优秀观点，附上一些我拜读的掘金文章：

1. 大白话DDD（DDD黑话终结者），概念解释比较舒服
2. 再探DDD以及美团的“野路子”，进阶思想说的很到位
3. 一文带你落地DDD，q&a部分蛮有意思
4. 为什么从 MVC 到 DDD，架构的本质是什么？
   ，图画的不错可以看看，卖课味太重了，大部分内容有点辣眼睛

想看这本书的契机其实来源于一个面试官。之前实习面试说喜欢看数据库，原因是一个项目涉及的数据库和产品业务高度相关，熟悉了数据库E-R图其实脑海里业务也就有数了。然后面试官说DDD设计模式比单纯的数据库设计更有业务价值。

工作了一年外加看了这本书之后，却是如此。企业中的数据库表可能服务于不同的组件，本身有概率会迭代得相当庞大，字段缩写晦涩难懂；外加表格之间的关系复杂，E-R就算有靠谱的文档说明也很难凭直觉区分成不同的业务领域。

优点：

1. DDD本身概念很火，学习一个很多人宣传推崇的概念很爽
2. 从需求产品这种比较高的层面自顶向下的设计思路，领域区分高内聚低耦合的核心思想还是有价值的，对于常常局限于单模块或单领域的开发、视野有限的人来说可以拓宽整体业务思维。技术不能脱离业务的角度还是很实用的

劣势：

1. 用词晦涩，外加中文版机翻味有点重，读起来并不顺畅。明明大白话就能说清楚的设计原则非得人为加密
2. 很多书中概念其实在微服务架构+模块内部的MVC分层结构（包结构合理清晰的前提下）已经覆盖了，在开源项目和工业实现中已经具备了，所以新知识点并不多。读完之后我还有印象的不过是领域建模的过程和事件驱动架构设计这两个地方😅，其他不过是对已有知识的包装
3. 概念大于实现，而且严格的DDD模式适用的实际场景并不多，在微服务的今天能带来的增量价值相对于重构的精力投入而言不一定大。为了技术而技术是不理智的也是老生常谈了，这也是DDD褒贬不一，落地案例少的原因吧

但是！DDD这本书已经是2003年的概念了，很多书中的内容已经深入人心没有新鲜感也是正常的事。虽然不知道为啥最近几年异常的火，有人说是因为卖课🤪