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

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

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

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

zhx870214
2019-11-27 13:16
感谢分享,项目做多了之后越来越觉得之前写的都是面向过程的代码。

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

猜你喜欢