SOA 与 DDD

SOA是技术架构方面,Evans DDD则是哲学方法论方面,所属方向不一样,或者说两者非常的无关。甚至是两个不同方向。使用DDD可以将系统从无到有到大建立起来,而大到一定程度,就需要SOA,整合异构。如果说DDDSOA有什么联系的话,那么组件Componen可能是他们中间的纽带。下面对这几个概念分析如下,不当之处请讨论。

SOA概念

SOA是一个很高的架构,使用EJB这样分布式组件以后才会考虑SOA,有过DCE (Distributed Computing Environment), CORBA (Common Object Request Broker Architecture), DCOM ( D istributed Component Object Model) 或者EJB/RMI (Remote Method Invocation)等分布式架构经验的,过渡到SOA是一个很容易的概念,否则,如果没有这样一个可伸缩的架构概念,SOA对于他们则特别难以接受,是一个非常陡峭的学习曲线。

在当前国内很多人以数据库为中心的软件思维,没有认识到数据库的不伸缩性,让他们去接受分布式组件概念都很难,更别说SOA,这也是SOA在国内喊那么多年,一直没有大规模应用的原因,
SOA和EJB一样对于一些人非常高端,接受起来不是一蹴而就,也不是我写两篇文章数据库死了就可以接受的了。这是一个整体素质和水平的问题。

一个SOA架构如图:

SOA是一个业务重用粒度很高的架构,属于一种粗粒度的服务,ESB是提供这些粗粒度服务之间沟通的一种渠道,ESB是让服务彼此交流通迅,是一种实现松耦合的面向服务的架构。

SOA和Component/EJB

使用EJB作为SOA服务实现有很多好处,是一个推荐理想做法,但是,EJB作为一种分布式组件技术,还是和SOA的服务有些区别。

首先,服务应该是无状态的,而组件component可以有状态,虽然EJB作为分布式组件是SOA服务最好实现,但是不是所有的组件component都能作为服务的。

其次, 组件component是一种细粒度,而SOA的服务是一种粗粒度,组件是为重用而设计的对象,而服务是为更好地伸缩性scalability 而设计的,注意,服务是偏重伸缩性的,如果说组件还和DDD有关,实现DDD思想涉及到使用什么样的组件路线,那么SOA就已经纯粹是一个完全伸缩性概念了。

不要以为使用了EJB就具有良好的可伸缩性scalability,分布式计算组件不代表良好的伸缩性scalability,因为他们粒度还是太细,粒度太细导致调用过分频繁,加重分布式网络负载。

一个业务功能会在很多组件之间来回不断调用,,而SOA则是客户端使用一次调用一个服务,解决这一个业务功能,显示简明扼要,一刀封喉,同时也因为性能问题,减少网络来回损耗,SOA提供减轻了的负载,同样的网络环境就能提供更多的功能负载处理,所以SOA伸缩性方面要好于EJB或CORBA这些细粒度组件。

组件的细粒度是因为使用Evans DDD等对象方法分析设计的结果,组件可以看成是一个打包的多个对象,也可以是一个对象,对象方法论Evans DDD建议我们不断分层,可以不止三层,五层甚至更多成,直至最大化松耦合,最后结果必然导致琐碎和粒度非常细腻。而SOA则是一个相反过程,需要让我们不断拔高。

SOA和Evans DDD

上面已经说过,SOA是一个着重功能块的架构,比如天气信息服务、google的查询服务,是粗粒度的,那么是不是使用SOA就无需DDD,打个比喻:DDD就是把东西切得很碎,而SOA则是打包,这两个是否没有关系呢?

我个人认为答案是否定的,如果没有很细腻的松耦合的分离,那么怎么有SOA的整块概念呢?碎块和整块本是一对矛盾体的两个方面,互相依赖相对的,如果失去一方,另外一方也就无法存在。

如果没有DDD这样OO分析设计,如果是围绕数据库分析设计,就很难使用上SOA这样的粗粒度又和具体技术无关的高级架构。

如果你没有OO细分概念,而是数据库驱动设计概念,那么你就可能会将数据库的CRUD作为服务提供出来,JDBC或Http都不是服务。不能将简单的增删改查这样细粒度服务作为SOA的服务,基于CURD以上应该是更复杂的可重用的组件,然后,在组件上面才会使用到SOA的服务。SOA是一个很高的概念,需要更高的向上思维。

可以看出:SOA服务是在松耦合组件分离后的再次打包,而Evans DDD则是一把切断组件关系的利刃。从这个方面看,DDD应该是更基础平台,万丈高楼平地起啊,而DDD是对象方法论集大成,集合分析模式和设计模式,当你掌握DDD以后,分布式组件EJB是你攻克的第二关,伸缩性scalability成为你架构习惯思维的一部分以后,才能真正进入SOA高端“仙境”。

参考文章:
http://www.theserverside.com/news/thread.tss?thread_id=44639

http://www.jdon.com/jivejdon/thread/34676.html

时间: 2024-12-18 00:47:06

SOA 与 DDD的相关文章

结合领域驱动设计的SOA分布式软件架构

引言 本文主要是参考Martion Fowler所著的<企业应用架构模式>与Eric Evans所著的<领域驱动设计>这两本泰山之作,加上本人在近年实际的工作过程中开发SOA系统所认识到的问题所写的一篇文章,欢迎各位点评. 最后两节  细说应用层 .系统总体架构是本文的重点,着重说明领域驱动设计与SOA之间的关系,对DDD有一定基础的朋友可以越过前面的几节,直接查看第七.八节. 源代码下载 (数据库可以在.edmx文件根据模型生成) 一.SOA与DDD的定义 SOA与DDD都是常用

NServiceBus官方文档翻译(一)NServiceBus 概况

NServiceBus 概况 NServiceBus 被设计用来组合面向业务的服务,它并不是用来替代诸如 WCF 一类的RPC技术. NServiceBus 不只包含通信模块,像其他成熟的SOA和DDD项目一样,它使用了多种组合的方法和技术. 本篇文章探讨了 NServiceBus 和微软相关产品的相似点和不同点. 相比 BizTalk 更接近 WCF 当人们听到“服务总线”这个名词时,一般会描绘出如上图所示的画面,像 BizTalk 一样所有的通信都经过一个中央结点.这实际上描述的是一个代理的

浅谈微服务的来龙去脉

作者:王清培(Plen wang) 沪江 公共业务平台 应用架构师 转载至沪江技术学院微信公众号 背景介绍 最近一段时间公共业务平台在进行大面积的重构,对原来的技术栈进行迁移,逐渐往Java.Go.Node.js等开源.自由为主的技术体系中过度. 虽然这主要是替换技术框架,但也是我们应用系统进行重新设计.业务流程重新梳理的一个好机会,我们将利用这次机会来重构之前发现的一些问题. Martin Fowler大师<重构>一书中有说过一句话,大概意思就是,"每次对原有系统进行修改调整的时候

linux-dns-11

1网卡设置配置文件里面DNS服务器地址设置,2.系统默认DNS服务器地址设置.3,hosts文件指定 生效顺序是: 1 hosts文件 ---- 2 网卡配置文件DNS服务地址 ---3 /etc/resolv.conf 查询方式 递归 : 客户端和本地DNS服务器的查询就属于递归查询,客户端发出查询请求后处于等待状态,本地DNS以客户端身份询问下一个DNS服务器,直到本地DNS服务器返回确定回复或否定答复 简记:我问你,你问他 迭代 : 根域名服务器提供顶级域名服务器ip ,loacalnms

DDD CQRS架构和传统架构的优缺点比较

明天就是大年三十了,今天在家有空,想集中整理一下CQRS架构的特点以及相比传统架构的优缺点分析.先提前祝大家猴年新春快乐.万事如意.身体健康! 最近几年,在DDD的领域,我们经常会看到CQRS架构的概念.我个人也写了一个ENode框架,专门用来实现这个架构.CQRS架构本身的思想其实非常简单,就是读写分离.是一个很好理解的思想.就像我们用MySQL数据库的主备,数据写到主,然后查询从备来查,主备数据的同步由MySQL数据库自己负责,这是一种数据库层面的读写分离.关于CQRS架构的介绍其实已经非常

SOA、REST 和六边形架构

SOA.REST 和六边形架构 上一篇:<IDDD 实现领域驱动设计-架构之经典分层> 阅读目录: SOA-面向服务架构 REST 与 RESTful 资源(Resources) 状态(State) 六边形架构 DDD 的一大好处就是并不需要使用特定的架构,经典分层架构只是一种,由于核心域位于限界上下文中,我们可以使用多种风格的架构,既然如此,我们应该把眼界看的更宽广些,有意思的东西多着呢. SOA 和 REST 这两个货,我们都比较熟悉,他俩并不是由 DDD 引入,但却可以适用于 DDD.我

.NET应用架构设计—工作单元模式(摆脱过程式代码的重要思想,逆袭DDD)

阅读目录: 1.背景介绍 2.过程式代码的真正困境 3.工作单元模式的简单示例 4.总结 1.背景介绍 一直都在谈论面向对象开发,但是开发企业应用系统时,使用面向对象开发最大的问题就是在于,多个对象之间的互操作需要涉及数据库操作.两个业务逻辑对象彼此之间需要互相调用,如果之间的互相操作是在一个业务事务范围内的,很容易完成,但是如果本次业务逻辑操作涉及到多个业务对象一起协作完成时问题就来了. 在以往,我们使用过程式的代码(事务脚本模式),将所有与本次业务事务范围内相关的所有逻辑都写在一个大的代码中

SOA架构设计经验分享—架构、职责、数据一致性

阅读目录: 1.背景介绍 2.SOA的架构层次 2.1.应用服务(原子服务) 2.2.组合服务 2.3.业务服务(编排服务) 3.SOA化的重构 3.1.保留服务空间,为了将来服务的组合 4.运用DDD+GRASP进行分析和设计(防止主观的判断导致错误的假设) 5.SOA分布式下的数据一致性 5.1.分布式事务(基于DTC的分布式事务) 5.2.事务补偿(提供正向或反向的操作来让数据在业务上是一致的) 5.3.异步EDA(基于异步事件流来实现柔性的分布式事务) 6.总结 1.背景介绍 最近一段时

学习~SOA面向服务框架

SOA面向服务架构 首先Martin Fowler提出SOA歧义Service Oriented Ambiguity,认为"什么是SOA"是不可能回答,因为不同的人意味着不同的事情,SOA意味服务接口,意味流程整合,意味资源再利用,意味着管制,在下面SOA组件图中,服务和服务消费者(客户端)之间存在多个约束,当一个服务显式暴露后,客户端能够通过绑定定位到该服务,相当于两者签订了合同,规定了合同内容和如何实施,具体合同的描述是通过消息方式进行: 由于Java等传统语言主要是以类表达对象,