理解ddd中的service
application-->serivce--->repository--->dao--->db
对于service的理解得重新认识.
过去把所有东西都是放在action里面,后来加了service,但是service与dao有重复.
有人提意,合并service,dao接口.
现在从DDD中重新学习service.
-----------------------------------------------------
我们知道,在领域设计中,划分为三种模型,分别为:实体(Entity)、值对象(Value Object)、和服务(Service)。其中Service与我们传统设计中的Service有什么不同呢?
让我们来回忆一下,通常我们针对将读写xml、资金转账等代码放在service中,可以看出,该层包括了两种含义,一种是与业务无关的,一种是与业务紧密关联的。领域驱动设计将这两层含义进一步划分,《Domain-Driven Design》中的例子那样:如果银行应用可以将我们的交易转化并输出电子表格文件,那么这种输出就应该是应用服务。而负责处理资金转帐的借贷关系,应该属于领域层,它包括了基本的业务逻辑,而技术层上的服务则根本没有任何业务含义。由此得知,将传统设计中的Service继续划分,得到应用服务与领域服务。领域层和应用层的服务是相互合作,由应用Service指挥领域对象来解决问题。
application-->serivce--->repository--->dao--->db
对于service的理解得重新认识.
过去把所有东西都是放在action里面,后来加了service,但是service与dao有重复.
有人提意,合并service,dao接口.
现在从DDD中重新学习service.
-----------------------------------------------------
我们知道,在领域设计中,划分为三种模型,分别为:实体(Entity)、值对象(Value Object)、和服务(Service)。其中Service与我们传统设计中的Service有什么不同呢?
让我们来回忆一下,通常我们针对将读写xml、资金转账等代码放在service中,可以看出,该层包括了两种含义,一种是与业务无关的,一种是与业务紧密关联的。领域驱动设计将这两层含义进一步划分,《Domain-Driven Design》中的例子那样:如果银行应用可以将我们的交易转化并输出电子表格文件,那么这种输出就应该是应用服务。而负责处理资金转帐的借贷关系,应该属于领域层,它包括了基本的业务逻辑,而技术层上的服务则根本没有任何业务含义。由此得知,将传统设计中的Service继续划分,得到应用服务与领域服务。领域层和应用层的服务是相互合作,由应用Service指挥领域对象来解决问题。