传统的开发模式是MVC的，如何基于现有架构做DDD的重构
在之前的开发中，整个业务就落一张履约表，模型都在一大坨
面向功能开发，比如 OrderCreateController -> OrderCreateService -> OrderCreateDao
一条路捅到底
那么做领域驱动设计落地呢？现有的开发模式肯定不行，DDD是以领域domain充血模型的开发模式，
按照领域收敛核心逻辑，在inf层操作中间件和组件
在应用层编排业务流程。
现在我们就要按照领域拆表，拆model
老表 —拆分—> 订单表 + 履约表 + 运单表
表的拆分即使领域的拆分
订单相关的核心逻辑收敛在订单域，
履约相关的核心逻辑收敛在履约域，
一个域，狭义的理解就是一个领域类，比如OrderDomain
拆完表后，先做的就是数据双写
保证新老表数据双写
要考虑的是，重构的同事还有日常的需求迭代的。
重构完成后，保证数据双写的同时，在业务流量入口处添加按商家的灰度开关，走到DDD重构后的逻辑，慢慢灰度小范围验证。
DDD落地有什么问题呢？
DDD落地实际没有特别权威和专业的开发规范和指南，很多书籍实际偏理论一点
可以理解DDD更偏是一种编程规范一点。
DDD很可能导致的问题就是代码演进成四不像，面向过程 + 面向对象 + MVC + DDD 。。。
还可能导致domain类的膨胀，加重维护负担，而团队内部本身开发素质都是不同的，每个人的代码风格和理解也可能不同，
如果再加上业务紧急，code review 不够严格，最终DDD的代码反而没有MVC的代码更直观更好维护
这感觉也是DDD最大的问题。
好的开发模式和开发规范，不一定要完全受限于具体的条条框框，而是团队内的领头羊制定好这一切的规范然后团队内成员按约定执行，并做定期的代码 code review。
而一个团队如果要落地DDD，也需要团队内有大佬对DDD有比较深的理解和落地经验吧。
说点什么
您将是第一位评论人！