【领域服务要起名为xxxDomainService】吗?
我目前个人的想法是,推荐使用xxxDomainService这种方式。有如下几个原因:
【1】一看名字就知道领域逻辑会封装在里面或者说它是入口。有些人喜欢直接把领域服务起名为类似xxxHandler,xxxxBuilder等,这种就不太好立刻识别到,它们是某个聚合的领域服务,感觉太分散了。当然这里并不是说所有的领域逻辑就一定得全部写在xxxDomainService里,这样会导致它太庞大了。当业务逻辑开始复杂后,你可以在领域层里写一些辅助类,帮忙分摊一些领域逻辑,比如xxxHelper,xxxHandler。共同完成领域逻辑,但是对外的话,就是一个xxxDomainService。
【2】,随着业务需求的不断变化,在应用层跨聚合的操作会越来越多。比如聚合A的应用层去调用聚合B的相关接口。如果聚合B的领域服务不是叫xxxxDomainService,你就得去问同事或者看代码才知道哪些领域服务类的接口是你能调用的。
我目前个人的想法是,推荐使用xxxDomainService这种方式。有如下几个原因:
【1】一看名字就知道领域逻辑会封装在里面或者说它是入口。有些人喜欢直接把领域服务起名为类似xxxHandler,xxxxBuilder等,这种就不太好立刻识别到,它们是某个聚合的领域服务,感觉太分散了。当然这里并不是说所有的领域逻辑就一定得全部写在xxxDomainService里,这样会导致它太庞大了。当业务逻辑开始复杂后,你可以在领域层里写一些辅助类,帮忙分摊一些领域逻辑,比如xxxHelper,xxxHandler。共同完成领域逻辑,但是对外的话,就是一个xxxDomainService。
【2】,随着业务需求的不断变化,在应用层跨聚合的操作会越来越多。比如聚合A的应用层去调用聚合B的相关接口。如果聚合B的领域服务不是叫xxxxDomainService,你就得去问同事或者看代码才知道哪些领域服务类的接口是你能调用的。
展开
6
1