很多DDD的文章都在说传统的编程方式是面试数据库编程，导致对象中只有getter,setter，也就是贫血模型，贫血模型是没有业务逻辑，面向过程设计，不符合面向对象设计原则。
对于这个结论我是同意的，但是对于造成的原因不是很同意。个人认为造成这个原因的主要原因还是在于长期以来的MVC这种模式只有纵向切分导致。如果结合横向切分，有没有DDD也无所谓。这里再引用一下驱动方法不能改变任何事情这段话，如果你能深入理解职责、封装。并随着业务的迭代，不断的重构你的代码，那么你不需要什么DDD,或者其他方法论。
使用职责、封装和组合；
以接口的视角思考，即“人们如何使用我的组件？”；
使用相关技术写好代码，包括可读性、信息性、简洁、自描述，尽量避免显式地使用模式；
有能力回答特定业务的“本质”；“本质”是一个模型，但不意味着类和方法，它意味着回答问题“这个业务如何真正地工作？”
因为这些约束，都是强迫你去思考，去做职责的思考，去做模块的封装。如果你/你团队成员已经领会其中的道理并很好的运用，还需要这些条条框框干吗呢？
下一篇领域与微服务划分，欲知后事如何，请听下回分解。
相关阅读
https://www.cnblogs.com/stoneFang/p/10888630.html
关注【方丈的寺院】，第一时间收到文章的更新，与方丈一起开始技术修行之路
