对于贫血的领域层,主要体现在两个方面,一个是没有领域业务对象的概念(领域模型中的聚合根),一个是没有明确的粗粒度的业务规则逻辑处理层。在这种情况下,原有的业务逻辑层变化为仅仅是DAL层的一个简单封装或通道,实际的业务处理全部转化到action层或dal层进行了处理,导致无法真正提炼一个业务模块真正应该具备的领域服务能力。
粗粒度的领域服务提供包括两个方面,一个是完整的领域业务对象提供的数据服务,一个是处理业务规则和逻辑用的业务服务。在领域驱动设计中,前者部分在仓储模型中完成,后者在service中完成。这里要注意DDD里面的service,和我们基于SOA分析和设计中的服务层仍然还是有差别,所有的共性的,应该提供给应用层访问的粗粒度的能力都应该抽象为服务层的服务。
在当前的领域分层架构中没有服务层的概念,在领域层和应用层都有服务,可以将服务层进一步抽取出来,服务层即向应用层提供所有的服务能力。这个服务能力不仅仅是原子服务能力,也包括了组合服务能力。对于服务层提供的服务能力,由服务层控制事务。对于进一步的服务编排,则在应用层进行完成,如果完全基于SOA参考架构,则在上面还会有BPM或BPEL层,重点是对原子服务进行组装和编排。
实体要考虑两个层面,一个是完全的data
entity,一个含操作的entity,为了考虑在SOA架构中的数据和操作分离,建议还是采用完全的data
entity实体,这个时候这种实体可以进一步作为跨层传输的DTO对象。而对于原有的DAO层,也不仅仅是实现数据的持久化,很多OR-Mapping操作也会在该层完成。数据层关注的是数据对象即和数据库一一映射的表,而领域层关注的是领域对象(可能涉及多张强聚合的表);数据层最终关心的是数据对象的持久化,而领域层关心的是业务对象全生命周期的管理。
在考虑了数据和操作分离后,对于聚合根的业务对象应该有一个专门的业务对象类,来处理所有和业务对象属性,状态变化相关的操作,即控制业务对象完整的数据和生命周期。而service类本身不应该对数据进行任何cud操作,service类的所有操作都应该转入到业务对象类中进行处理。在这种模式下service类目的仅仅是处理业务规则和逻辑,最终处理结果的落地仍然通过业务对象类来完成。
一个完整的业务系统的构建,不是简单的横向分层,还包括了纵向的分业务模块和业务组件。在领域驱动设计里面没有太多的对这两块结合的描述。在这里要注意两个方面的内容,一个是每一个业务组件都会向上层提供领域服务能力,第二每一个业务组件也会向其它业务组件提供领域服务能力。如果考虑业务系统开发的完全组件化架构和后续的分布式组件部署,那么就需要考虑对于向外部提供的领域服务,需要采用根据松耦合的服务方式向外部提供和发布(soap
web service/rest
等),而对于内容提供的领域服务即可以仍然沿用常规api方式。对于同一个业务模块而言,如果要考虑到后续的领域服务层也可以单独的分层部署,那么所有的领域服务都需要通过松耦合的方式向外发布。
青春就应该这样绽放 游戏测试:三国时期谁是你最好的兄弟!! 你不得不信的星座秘密