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