个人对Banq的思路很有感触，我想从另一个角度说说个人对service层与领域对象关系的看法，即从成本角度。老说需求变更，其实真正的业务变化并不多，更多的是需求人个人意志影响的使用方式的变化（或者叫应用功能的变化），应对这两种变化，“丰富”的service就显得比较困难，注定增加开发成本。原因是里面的东东太多，没有分清应用功能和真正的业务逻辑，交织在一起。Banq的思路其实是将应用功能和真正的业务逻辑分离，service描述应用逻辑满足用户的功能要求，领域模型描述业务的本质和客观规律，这样针对应用功能的变化和真正业务逻辑的变化，可以有的放矢，更有针对性的解决。回归于OO，OO的出现就是为了简化解决大规模复杂问题的难度，悟道细品。

banq 大哥，Martin Fowler 的著作《企业应用架构模式》看了一部分，感觉你所说的贫血模式+服务层，就是书中第二部分（模式）中说的“事务脚本”，据我的理解，如果业务逻辑不很复杂的情况下，“事务脚本”这种模式是完全可以胜任的，即业界常用的三层架构+贫血模式，这种用法使用了这么长时间了，有它存在的价值，当然肯定要敢去怀疑它。

在业务逻辑比较复杂的情况下，支持 banq 所倡导的 DDD。

看了这篇文章很有感触，感觉DDD应用在复杂的业务逻辑中确实很有用，不知道有没有可以参考的用SpringBoot 框架实现DDD的例子，想用，但是不知道如何实现。。。

感谢分享，项目做多了之后越来越觉得之前写的都是面向过程的代码。

我很赞同banq，以及他的举例，也很赞同mlang 的评论。我结合自己当前写的DDD，确实可以通过这种形式，大量减少根据日渐增多需求，来针对service内部逻辑的维护量，同时也能很好的使用业务领域发挥业务逻辑的维护，其实确实核心的业务逻辑几乎是很少会改动的，改动的就是关于应用逻辑的变化较多

我很赞同banq，以及他的举例，也很赞同mlang 的评论。我结合自己当前写的DDD，确实可以通过这种形式，大量减少根据日渐增多需求而带来的工作量，来针对service内部逻辑的维护量，同时也能很好的使用业务领域发挥业务逻辑的维护，其实确实核心的业务逻辑几乎是很少会改动的，改动的就是关于应用逻辑的变化较多

五一好好研究一下：）