自从看了后有种豁然开朗的感觉 原来以前编码的习惯叫做事务脚本,active record,query object 我还是比较习惯三层
自从看了<ASP.NET设计模式>后有种豁然开朗的感觉.原来以前编码的习惯叫做事务脚本,active record,query object.
我还是比较习惯三层架构/或其变体这种编码习惯.但是到了后期发现一个庞大的项目后期维护起来真的很恶心.事务脚本有一个状况就是我一个功能要修改.我不知道具体哪个类哪个方法对应这个功能,而active record呢,在涉及到多个表的先后操作感觉又有点奇怪.感觉这个方法不应该放在这里,但是又不知道该放在哪里.
而我所理解的领域驱动设计,是一种建模的思想.这种思想把方法的布置放在一个领域对象中.领域对象对我来说就是一个抽象的名称类型.比如消费者,服务提供者,订单,各种交互图中的对象.比如有一个银行家领域对象,无产阶级领域对象,无产阶级找银行借钱就是在无产阶级类里面有一个借钱的方法,该方法的参数包含银行家对象还有一些需要的"手续".我个人是不喜欢把领域模型弄的很充血的,因为好多属性需要在实例化的时候注入.方法一多怎么办?但是必要的主键id我还是会加上去的.
那么这个借钱的方法主体无非就是,我要根据这些手续判断借钱是否合法.而数据来源不在该方法获取而是作为参数.那么数据来源写在哪里呢?写在领域服务里的仓储接口里面.这样就没什么问题了.业务变更的时候,我们只要改这个借钱方法了,如果需要其他手续?我想到时会考虑把"手续"作为借款人的属性吧.
