2013-12-16 17:00 "@
sinaID99267"的内容
这个问题其实是SOA架构本身的问题,因为Spring是SOA架构中的一个实现,所以也带有这个问题。
SOA架构的问题来自于其面向服务自身,用服务来对业务切分,这样,可能破坏业务自身的聚合性。也就是说,业务逻辑会散落在多个服务之中,想修改代码,要修改多个服务。
服务的抽象主要是从重用角度抽象的,如有很多客户都要下订单,那么我们就抽象一个订单服务提供给这些客户;然后又有很多客户要签合同,那么我们就抽象一个合同服务于这些客户;这些服务都是从对外接口的角度粗粒度设计,或者只是纯粹从业务流程来考虑的,并没有从业务内部领域逻辑角度考虑,有人说,这两者不是一样吗?有时一样,有时不一样。比如某个单位无论给订单客户还是合同客户,都有一个统一的最低底线价格,按照面向服务的设计,这个底线价格会各自写到订单服务和合同服务中。
有人说,那订单服务与合同服务共同重用一个实体名叫价格策略。这种重用其实引发了依赖,紧耦合,破坏了松耦合。
比如订单服务代码:
|
合同服务:
|
这两个服务都依赖PricePlocy,就算PricePlocy是个接口,如果接口发生变化,这两个服务的代码就发生变化。
那么有人说,将PricePlocy独立出来成为一个PricePlocyService,三个服务通过ESB消息总线交互。那这样服务的粒度就太细了,如果再发生PricePlocy2,难道你再搞个PricePlocy2Service吗?
这里就发生了重用与松耦合矛盾的情况,重用的角度是从为客户服务这个外部因素考虑的,而不是从业务内部去发现领域规律。
如果从内部去考虑,发现内部聚合,自然外界接口就松耦合,比如订单服务和合同服务,背后有一个价格制定策略,这个是核心,是DNA,我们可能将定价算法作为一个聚合根,订单和合同只是定价这个实体的外部两个服务接口而已。
面向服务和面向领域的区别就如同销售部门和产品部门的区别一样(也类似项目和产品的区别),一个从外部考虑,一个从内部考虑,考虑方向完全不同。但是两者可以互补。如果片面从外部考虑,导致各个服务对领域的强行肢解,流程变动方便了,但是业务逻辑的一贯性凝聚性被破坏了。销售部门经常拉产品部门工程师为客户服务,结果耽误了产品自身的研发一贯性。
[该贴被banq于2013-12-16 21:33修改过]