背景

正所谓有人的地方就有江湖，有设计的地方也一定会有架构。如果你是一位软件行业的老鸟，你一定会有这样的经历：一个业务的初期，普通的 CRUD 就能满足，业务线也很短，此时系统的一切都看起来很 nice，但随着迭代的不断演化，以及业务逻辑越来越复杂，我们的系统也越来越冗杂，模块彼此关联，甚至没有人能描述清楚每个细节。当新需求需要修改一个功能时，往往光回顾该功能涉及的流程就需要很长时间，更别提修改带来的不可预知的影响面。于是 RD 就加开关，小心翼翼地切流量上线，一有问题赶紧关闭开关。

面对此般场景，你要么跑路，要么重构。重构是克服演进式设计中大杂烩问题的主力，通过在单独的类及方法级别上做一系列小步重构来完成，我们可以很容易重构出一个独立的类来放某些通用的逻辑，但是，你会发现你很难给它一个业务上的含义，只能给予一个技术维度描绘的含义。你正在一边重构一边给后人挖坑。

在互联网开发“小步快跑，迭代试错”的大环境下，DDD 似乎是一种比较“古老而缓慢”的思想。然而，由于互联网公司也逐渐深入实体经济，业务日益复杂，我们在开发过程中也越来越多地遇到传统行业软件开发中所面临的问题。

怎么解决这个问题呢？今天团长要分享的这份：DDD领域驱动设计三部曲！就可以帮助你完美地解决这些问题！