DDD 思想
设计模式的 DRY 原则（Don’t Repeat Yourself）让我们尽可能地不要编写重复的代码。
但是在复杂工程中导致的问题就是，DRY 的函数会被大量的地方引用，导致其内部逻辑需要考虑各种情况，逻辑极其复杂，修改风险也极高。
这么看来，DRY 也没有那么好，重复代码反而可以降低后续的修改风险，日后可以根据业务需要再进行灵活整合。
复用
什么情况下，复用能够提升产品的核心竞争力呢？
- 复用之前具有竞争力的技术模块，让过去的成功经验助力未来的产品成功
- 给用户提供一致的体验，考虑用户的使用习惯，降低学习成本
复用不同模块能取得效果的程度也是不同的，复用什么样模块更有可能获得上述两点效果呢？DDD 中对子域的划分或许能够给我们答案，在 DDD 中软件存在三种子域：
核心子域
- 特点：能够给公司带来核心竞争力的领域模块，拥有很高的复杂度和差异化价值；
- 案例：比如滴滴的司机调度算法，支付宝的交易系统，钉钉的 IM 系统等等；
- 复用策略：属于该子域的模块应该尽可能地复用， 将其竞争力也注入到其他产品，甚至投入精兵强将，提升其可扩展性，进一步拉开和竞争对手差距。
支持子域
- 特点：用来支撑核心子域，但是不能带来竞争力；
- 案例：比如运营管理系统，后台排查系统等等；
- 复用策略：因为不能带来核心竞争力，不如各个业务根据自己需求，使用脚手架快速搭建，定制起来还更加方便。
通用子域
- 特点：通用的业务或者技术问题领域， **比较复杂， 却不能给企业带来核心竞争力。**好在一般有现成的解决方案，可以直接采购；
- 案例：比如财务系统，可以直接采购用友，金蝶；分库分表，消息队列可以直接使用开源软件，或者购买云上解决方案；
- 复用策略：尽可能复用，但是复用的目的与核心子域不同，主要是为了降低研发成本。
以 DDD 中经典的货运管理系统为例（简化）：
因此 DDD 要求技术和业务深度结合，如果不了解业务的话，单从设计原则角度，很难理解为什么要复用一个技术模块。