一个需求非常确定的项目，不管多复杂，都没有必要非转型成DDD，短平快的设计方式更为快捷。
如果项目中有很多不确定性，以往的设计模式会遇到非常多的变数，这时DDD就是一个很好的选项了。
DDD 重构
- 抽象数据持久层 - 建立仓库（让业务逻辑不再需要面向数据库编程，而是面向实体编程）
- ACL 防腐层 - 抽象第三方服务（防止第三方服务状态不可控，入参出参强耦合的问题）
- 重构业务逻辑
a. 使用值对象（具有业务意义的对象）
i. 比如做参数校验，避免类似逻辑分散出去，污染系统代码
b. 使用充血模型改造实体类，保留改变状态的方法
c. 使用领域服务封装实体逻辑（跨领域对象的行为）
改造之后：
- 最底层不再是数据库，而是实体(Entity)，值对象(ValueObject)，领域服务(Domain Service)。这些对象都不依赖任何外部服务和框架。这些对象可以打包成一个领域层(Domain Layer)。领域层没有任何外部依赖关系。
- 原有的Service层，经过重新编排后，只依赖于一些抽象出来的防腐层(ACL)和仓库工厂(Repository)。他们的具体实现都是通过依赖注入进来的。他们一起负责整个组件的编排，这样就可以把他们打包成一个应用层(Application Layer)。应用层依赖领域层，但是不依赖具体实现。
- 最后是一些与外部依赖打交道的组件。这些组件的实现通常依赖外部具体的技术实现和框架，可以统称为基础设施层(Infrastructure Layer)。
开发业务时，可以优先开发领域层的业务逻辑，然后再写应用层的服务编排，而具体的外部依赖与具体实现可以最后再完成。整体就形成了一种以领域优先的架构形式。
传统 MVC 事务脚本式编码的问题
- 代码层面的软件老化风险（代码不断膨胀）
a. 数据来源被固定
b. 业务逻辑无法复用
c. 业务逻辑与数据存储相互依赖 - 架构层面的软件老化风险（不敢升级，不敢写新功能）
a. 数据结构变更
b. JDBC依赖调整
c. 第三方服务变更
d. MQ中间件调整 - 随之而来的实施及测试问题
a. 设施搭建困难（依赖的外部组件太多）
b. 测试用例覆盖困难
