关于使用DDD的意义

Question

我理解DDD就是一套方法论
一个作用是用于拉齐项目中各个角色对于需求的认知，高效率的让项目中涉及的“知识”在团队内流转，这个是战略设计的作用
另一个作用就是将战略设计划分的领域模型，通过使用战术设计的各种“武器”，比如实体，值对象，仓储层，防腐层等等，将领域模型落地成高度抽象且领域层稳定的代码

但是我有个问题是在DDD中是不是战略设计意义要大于战术设计，因为我之前在做代码设计的时候，那时候不知道防腐层等概念，但是还是会做类似的抽象，经过良好抽象的代码即使是那种“事务脚本”的形式也是稳定的，所以我感觉如果仅仅是代码层面的问题只要是进行了良好抽象其实无论是面向数据还是面向领域是没有区别的？

问这个问题的原因是我在之前做项目的时候提出要使用DDD，然后我的老板问为什么要用，我表达了战术设计能够指导代码抽象等观点，然后我的老板说这是代码设计层面的问题，我感觉我没有办法反驳

辛苦老师能就为什么要使用DDD这一点给出指导意见，它和面向数据库表开发有什么区别，因为我理解只要做好代码设计，即使不用DDD，而是面向数据库表开发，也能搭建一套稳定的代码结构

Answer 1

尤达_技术咖啡 2021-10-27 09:16:34

1. DDD是否战略设计的意义要大于战术设计？

我的回答很明确：“不是”。战略设计的推行的确更容易，毕竟，拍脑袋做个领域拆分，再拍脑袋做个限界上下文划分，一般人也不知道你拆分的合不合理，好像也不用影响代码编写。但是必须要说，虽说架构设计有它的艺术性，但是归根结底是工程领域的事情，你的划分还需要验证。战略设计和战术设计的界限并不是那么清晰的，举个例子，我们一般认为寻找聚合是战术设计还是战略设计？一般认为是战术设计对不对？但是聚合同时又能够指示限界上下文的边界，限界上下文划的对不对，聚合找出来之后就一目了然了，甚至可以先找聚合，再划限界上下文，在事件风暴建模法里尤其可以这样。战术设计中如果发现战略设计不合理，那就要回过头来改战略设计。

2. 模型驱动设计和面向数据库表的设计有什么区别？数据驱动的缺点是什么？

数据驱动的设计是依赖底层设施的，对于“汽车”这个对象，如果使用MongoDB来做存储，可能只需要一个文档就可以了，而如果要用关系型数据库做存储呢，可能要拆分多个表，当然，针对不同的业务，表的设计可能不太一样，但是这个时候的考量点，主要是性能，以及查询的复杂度。

直接从表结构开始设计，可能会导致两种情况：

第一种：在后续的代码设计中，程序员为了赶时间，或者处于惰性，直接按照表结构来设计领域模型，或者尽量使模型向表结构靠拢。这种情况当然就完全背离了DDD的模型驱动原则，并且使业务代码被底层的技术实现绑架。这里的底层就是指数据的存储方案。举一个现实中完全有可能出现的例子：在业务的初始阶段，假设我们把“汽车”这个实体，分成多个表来存，包括“发动机”表、“轮胎”表等等。但是，随着业务的发展，数据量越来越大，查询的复杂度也越来越高，我们发现，关系型数据库已经逐渐不能满足我们要求了，我们的存储，需要切换到MongoDB，而且需要借助ElasticSearch来提供更复杂的查询功能。如果我们之前使用的是基于表结构的建模，可想而知这个时候代码需要做出的调整是非常大的，因为代码和存储方案没有分离，代码依赖的存储方案发生了变化。反过来，如果之前遵循的是DDD的模型驱动设计原则，那么这个时候只需要修改资源库的实现就可以了，业务代码不用做任何调整。

当然，不排除存在第二种情况：那就是即便使用数据驱动设计，由于程序员的素质极高，也能在没有DDD思想指导的情况下，做出与DDD类似的设计。这就涉及另外一个话题了：方法论到底重不重要？理论的作用有两点：1. 它使好的结果可重现，而且可复制，基于有效理论的指导，甲架构师针对A项目和针对B项目的设计都能达到比较好的效果，不会因为设计B项目的时候多喝了几杯，就做的一塌糊涂；也让甲架构师和乙架构师对某个项目的设计不会差太多，让更多人能做出好的设计。2. 它提供了一种能够提前对架构设计进行评估的方法，你说你设计的架构天下第一，极具灵活性，那么怎么证明呢？上线后再看？显然，对大型项目来说，“上线再看”是用项目乃至公司的性命在赌，所以需要一种思考和讨论的框架来提前对设计进行讨论和验证，DDD就提供了这种思考和讨论的框架。

• 革凡 #1

  老师，我觉得问题是他应该比较年轻哈。
  没经历过下一个订单，可能经过几百个几千个辗转腾挪的操作你就明白ddd的价值。大一点企业几乎都是ddd架构。这不是新技术而是没经历过大厂没参与核心业务开发几乎接触不到。所以才会有这些疑问哈。程序员内卷ddd是未来趋势。老师快点更新哈😊。

Answer 2

革凡 2021-10-28 17:55:26

。。。老弟，我只能说你有点可爱哈。首先老板和研发利益不同。代码设计好对老板来说浪费时间，浪费金钱，没有效果。老板也不考虑代码多整洁。总体来说，这是老板花钱和时间精力让你提升。所以说你不是说不过老板，而是你根本没有了解你们老板，所以你不可能说服他。

• 革凡 #1

  没经历过下一个订单，可能经过几百个几千个辗转腾挪的操作你就明白ddd的价值。大一点企业几乎都是ddd架构。这不是新技术而是没进过大厂没有成为核心开发几乎接触不到。所以你才会有这些疑问哈。程序员内卷ddd是未来趋势。

• 绽放123 回复 革凡 #2

  这几百步操作其中一个操作代码写错了，导致数据错误且并不发生实际异常，这种要怎么测试呢？