发帖    主题    评论    推荐    标签    作者    订阅    查搜    注册   登陆   关注
 
面向对象 设计模式 领域驱动设计 企业架构 框架 开发教程 微服务 CQRS 扩展性 并发编程 事件溯源 分布式 SOA
1 2 下一页 Go 2

面向服务和面向领域的不同

              
2013-12-16 20:57
赞助商链接


2013-12-16 17:00 "@
sinaID99267"的内容
想求老大进一步用代码的方式来阐述一下这个问题,最好是一个简单易懂的示例,谢谢! ...


这个问题其实是SOA架构本身的问题,因为Spring是SOA架构中的一个实现,所以也带有这个问题。

SOA架构的问题来自于其面向服务自身,用服务来对业务切分,这样,可能破坏业务自身的聚合性。也就是说,业务逻辑会散落在多个服务之中,想修改代码,要修改多个服务。

服务的抽象主要是从重用角度抽象的,如有很多客户都要下订单,那么我们就抽象一个订单服务提供给这些客户;然后又有很多客户要签合同,那么我们就抽象一个合同服务于这些客户;这些服务都是从对外接口的角度粗粒度设计,或者只是纯粹从业务流程来考虑的,并没有从业务内部领域逻辑角度考虑,有人说,这两者不是一样吗?有时一样,有时不一样。比如某个单位无论给订单客户还是合同客户,都有一个统一的最低底线价格,按照面向服务的设计,这个底线价格会各自写到订单服务和合同服务中。

有人说,那订单服务与合同服务共同重用一个实体名叫价格策略。这种重用其实引发了依赖,紧耦合,破坏了松耦合。

比如订单服务代码:

public class OrderService{

public int getPrice(PricePlocy pricePlocy){
..
}
}


合同服务:

public class ContractService{

public int getPrice(PricePlocy pricePlocy){
..
}
}


这两个服务都依赖PricePlocy,就算PricePlocy是个接口,如果接口发生变化,这两个服务的代码就发生变化。

那么有人说,将PricePlocy独立出来成为一个PricePlocyService,三个服务通过ESB消息总线交互。那这样服务的粒度就太细了,如果再发生PricePlocy2,难道你再搞个PricePlocy2Service吗?

这里就发生了重用与松耦合矛盾的情况,重用的角度是从为客户服务这个外部因素考虑的,而不是从业务内部去发现领域规律。

如果从内部去考虑,发现内部聚合,自然外界接口就松耦合,比如订单服务和合同服务,背后有一个价格制定策略,这个是核心,是DNA,我们可能将定价算法作为一个聚合根,订单和合同只是定价这个实体的外部两个服务接口而已。

面向服务和面向领域的区别就如同销售部门和产品部门的区别一样(也类似项目和产品的区别),一个从外部考虑,一个从内部考虑,考虑方向完全不同。但是两者可以互补。如果片面从外部考虑,导致各个服务对领域的强行肢解,流程变动方便了,但是业务逻辑的一贯性凝聚性被破坏了。销售部门经常拉产品部门工程师为客户服务,结果耽误了产品自身的研发一贯性。

[该贴被banq于2013-12-16 21:33修改过]

6
2013-12-17 10:02

结合我以前一篇帖子:依赖注入与事件编程
http://www.jdon.com/45264

文章提出了依赖注入的一个问题。

这里总结一下:
聚合 >松耦合>重用 ==> 事件驱动>依赖注入>继承

上面这篇文章是证明"事件驱动>依赖注入",至于“依赖注入>继承”见这个帖子:使用组合+依赖替代继承案例,虽然使用的AngularJS的依赖注入,但是原理适合所有编程语言:
http://www.jdon.com/45895

相关参考:
http://www.jdon.com/designpatterns/ooprimer.html
[该贴被banq于2013-12-17 10:07修改过]

2013-12-19 09:16

Spring 并不是SOA,尽管它很像(各种Service)。

Spring与SOA的问题应该是:他们的切分没有基于一个逻辑系统,所以往往会有冗余和空白。逻辑不是由一个个Service组成,而是由语言组成的(语言是逻辑的载体,曾经某道友提过“原语”,也是接近这意思)。Service并没有语言特性,也没有处于语言外的逻辑系统特性,于是它所切分的逻辑是混乱的。

让程序构成语言,再用语言表达逻辑,这才是出路,否则表达业务逻辑就是空谈。业务逻辑是逻辑,什么是逻辑?你的代码做到了吗?

对于依赖注入,这东西根本不是谈逻辑的。考虑传统编程思想,DI的最大问题是不在控制范围之内。无论高内聚低耦合,还是全内聚零耦合,我认为这些问题是特定语言引起的,思考下我们的自然语言,有考虑过这些问题么?
[该贴被SpeedVan于2013-12-19 10:05修改过]

2013-12-19 11:59


2013-12-19 09:16 "@
SpeedVan"的内容
Spring与SOA的问题应该是:他们的切分没有基于一个逻辑系统,所以往往会有冗余和空白。 ...


赞同,它们其实类似一个以项目决定一切的公司,公司老总是销售出身,眼睛只盯客户,这其实是第一个层次朴素的经商理念,真正一流企业是做标准,是保持这个行业的领域创新的Number 1。

我在另外一个帖子:http://www.jdon.com/45998#23144164也谈了服务的定位以及与CRUD区别:

基于领域分析后的新Service服务如同一个broker,也就是商人,做倒进倒出生意,把工厂(领域)的产品卖给客户,自己并不生产产品(业务逻辑)。

至于CRUD放入数据存储中,也就是Respository仓储中,CRUD本来就是数据存储的概念,不是业务领域概念,这个前提是你的系统复杂,不是简单得只有CRUD,那么DDD不适用。

DDD是在CRUD基础上有复杂业务逻辑,SOA解决了CRUD基础上的流程逻辑,但是并没有解决领域逻辑,聚合以及聚合的状态变化,聚合状态是因为受到外部流程变动而变化,但是聚合状态不是全局变量,不是流程想改就改,得通过领域规则这一关。

打个比喻,居委会要举行选举,选举有选举的流程,其中一个步骤是通知你参加,但是你可以不参加,不能因为外部流程,你没有自己的领域规则。

所以,领域要和两个敌人做斗争,前面是商人SOA服务,后者是数据库,和这两者划清界限,领域层就自然出来了。

与数据库划清界限是有关建模方面参考:建模风暴:
http://www.jdon.com/45999

总体来说:在需求分析这块经历三个阶段:
数据驱动SQL ---->服务驱动SOA ----->领域驱动

一个结合领域驱动+服务驱动SOA+数据驱动SQL架构图应该如下:

[该贴被banq于2013-12-19 12:51修改过]

2014-01-18 10:38

"这两个服务都依赖PricePlocy,就算PricePlocy是个接口,如果接口发生变化,这两个服务的代码就发生变化。"
“依赖注入”还有个名字“控制反转”,因此前述语句的问题在于没有彻底理解“反转”一词,接口应该是调用方定义和实现,实现一般采用适配器模式来做,因此,接口是调用方拿来隔离调用依赖变化的,变化即隔离在适配器实现中,唯一不变的是变,变是好事,变是成长,关键是如何隔离变,“反转”至关重要!

2Go 1 2 下一页

赞助商链接

赞助商链接

返回顶部

移动版 关于本站 使用帮助 联系反馈 最佳分辨率1366x768
OpenSource JIVEJDON Powered by JdonFramework Code © 2002-20 jdon.com