谢谢banq,我又重新看了一下,原来是之前看的太粗心,其实这些概念在里面都有!但是,好像banq在打包策略上有些复杂,也是导致我一开始没有找到正确实现的原因:
我有几个疑问:
1.在service包下面,正如您所说,除了ForumService以外其他都是领域service,但如果都放在同一个包下面,是不是容易造成混淆,我们的领域层服务和应用层服务都在一起,这样当需要扩展其他服务的时候也很容易把领域服务和应用层服务给混淆在一起?最终导致领域概念不能内聚?
2.Repositoy和factory都在repository包下面,但是他们的职责和用处都是不同的,能有更好的办法把它们分开吗?
3.Evans建议按照领域概念进行打包,那是否意味着同属一个业务范围里的实体/值对象,以及它们的factory/repository,还有这个概念领域的service都放在一个包里?
--假设我们想要将领域核心(包括模型和业务规则)移植到另一个框架(甚至平台)的时候,如果能准确地定位到所有领域核心概念的实现类,就可以只把整个Domain相关的包拿出来,从而实现领域核心的重用而不仅仅是代码片断的重用!
也许我的想法比较幼稚,目前估计要做到这一点估计不太可能.但是DDD的提出我想一方面可以应对领域本身的业务变化,另一个远见之处可能在于实现业务级核心的重用.
我们的技术不断在发展,各种应用层的工具也层出不穷,所以应用/UI/基础架构都是可以被替换的.但是一个行业的业务模式变化却相对稳定.
所以,如果能通过DDD的思想,把一个行业的核心概念以软件代码的方式进行精练和重用,也许能实现我们领域建模的终极目标吧?
--所以,对于打包的方法,我肤浅以为是应该将领域层的整个概念很好的封装起来,但是不知道banq您是否有其他的考虑?请说一下您的看法!!!