1回答

尤达_技术咖啡

2021-10-29

DDD一个重要目标就是避免过度设计，如何避免过度设计呢？就是让代码跟着业务走，而不是让程序员自由发挥。怎么样让代码跟着业务走呢？一是按照领域专家的描述来建立模型，建立出来的模型团队里所有人都要能够理解而且认可。

出现感觉被过度设计的情况，有两种可能性。

一种是系统本身业务逻辑不复杂（有可能技术要求高，对性能和并发有比较高的要求，但是业务不复杂），甚至根本就不需要领域专家参与。这里我们要说明一点：DDD不是银弹，它和设计模式以及面向对象不一样，它的出现只是为了辅助业务复杂系统的分析和设计，并不是为了解决所有代码结构的设计问题。很多人对DDD粉转路，就是因为希望用它来解决所有代码设计问题，然后发现不能满足自己的要求。

第二种情况就是模型本身有问题，如果模型的确遵从领域中的业务逻辑，每个领域对象连领域专家和产品经理都应该能理解，因为本身就是通用语言里的内容。既然程序员都要先了解业务流程和业务需求才能开发，怎么可能新来的人无法理解呢？Eric Evans有讲到过，建模不是做数学题，同一个领域可以建立不同的模型，要从里面挑选一个最优的模型，这个最优模型要很好地衔接业务和实现，两边都能懂。整个DDD的战术设计，讲的就是这个东西，为什么我们要有聚合这个概念？因为它能比较好地衔接领域中出现的业务实体和这个实体在系统中的技术实现。现实世界中有个汽车，系统中就有个汽车，现实世界中有个发动机，系统中就有个发动机，这不是很好理解吗？反倒是很多人用习惯了的service、manager这种东西，在领域中没有任何体现，只是程序员自己的抽象，仅仅是由于用习惯了，才觉得它好懂而已。试想一下，如果我们之前从来没见过service、manager这种东西，会觉得它好懂吗？为什么启动汽车这个动作，不是放在汽车的类里面，而是一定要放到service上？service到底是个什么？能说清楚吗？产品经理在修改业务流程的时候，会管你manager是什么意思吗？跟他说：“这块不好改啊，我的manager是这么写的，真不好意思啊。”你猜他是会理解同情还是会去投诉？所以我们觉得service、manager好懂，仅仅是因为习惯它们而已，并不是它们真的很合理，更不表明代码只能这么设计，让代码具备更大的可维护性和可变动性，王道就是让模型和架构的设计跟随业务，代码跟业务保持一致，业务小改，代码就小改，业务大改，代码就大改。业务要大改，产品和业务不会痛的吗？大改之下，除了代码重构，其他方面的成本更高。当然DDD也有资源库、领域服务这种抽象，DDD也强调，这种抽象是接近业务侧的，需要让领域专家和产品经理能够理解，换句话说，如果产品经理不知道你说的银行账户资源库是什么意思，那就不要用它。

0

1

革凡

老师，就等你第三章哈。

2021-11-02

共1条回复