谈领域服务

标签: IT咨询 | 发表时间:2013-05-17 22:01 | 作者:人月神话
出处:http://blog.sina.com.cn/cmmi


对于跨系统和模块间的SOA服务识别和分析我前面文章谈的比较多,这块的SOA服务重点是实现跨系统和模块的业务交互和协同,而对于领域服务而言则更加关心的是对于单个系统或模块,其应该如何抽象领域对象并将其能力以粗粒度服务方式保留给应用层用。在领域建模中的整体思路中,我们做两个层面的理解,其一是领域模型层重点是隔离传统的数据表并抽象为领域对象;而对于领域服务层重点是则将应用层和领域模型层解耦,模型层提供的能力是以领域服务的方式暴露到应用层使用的。

对于最贫血的领域服务层,就是一个DAL层封装的服务化,即只提供数据库表CRUD能力的服务化,在这种情况下基本满足所有的业务处理和应用需求,但是领域服务层没有任何领域逻辑,也没有领域对象的转换。而我们这种需要的领域服务主要包括三个方面的内容,一个是领域对象识别,然后将领域对象的类似CRUD操作暴露为服务;其二是对于核心的业务规则的识别,将业务规则识别为业务服务;其三是组合服务,根据业务场景需要将几个原子服务组合为一个更大的服务。

领域对象我前面已经谈到过,领域对象是具有完整相同的生命周期的对象,领域对象中的各个子对象不能脱离主对象独立存在,如我们经常说的订单,合同,供应商都是领域对象;但是这些领域对象在后台往往存在多张一对多的数据表,如订单至少包括了订单头和订购明细信息等。在领域对象识别中必须要首先识别核心的实体对象,在根据实体对象的属性需求来识别值对象,领域对象识别清楚了再根据业务场景的需求考虑领域对象的能力暴露。

领域对象中有一个核心就是将数据库表对象转化为领域对象,并将领域对象的能力暴露为粗粒度的服务,即数据库的CRUD能力转换为了对象的生命周期操作能力。但是在这种分析模式下容易遗漏业务规则转换为业务服务部分的能力需求,这类业务服务往往需要在对象关联依赖和真实业务场景和用例活动中才能够识别。举例来说供应商领域对象开始只识别了供应商的增删改查的对象处理能力;但是在我们做采购订单和合同的时候,有一个业务规则是需要校验供应商是否有效?在这种场景下我们需要将这种独立可复用的业务规则转化为业务服务,这种业务服务相当多,也可复用,属于我们经常说的粗粒度服务范畴。还有一类是组合服务,跟业务流程中的子流程或活动相挂钩,如银行转账,资产调拨,供应商合并,单据提交(单据保存+流程启动)等,都是典型的组合服务,往往需要调用多个原子服务或原子API操作才能够完成。这种组合服务能力可以进一步在领域服务层进行封装。

在引入了领域对象层和领域服务层后,需要对传统的分层架构进行调整,首先是引入领域对象,对原有的数据库表对象进行第一层抽象,数据接口转换为对象接口;其次是对原有的展现层和逻辑层进行解耦,引入领域服务层,在领域服务层需要承载业务逻辑,但是又不是完全承载;初步思考的是原有的业务逻辑层的内容有1/3左右划分到应用层;而2/3左右能够下沉到领域服务层。领域服务层贫血很多时候可以追溯到原有分层架构中本身的业务逻辑层就贫血,业务逻辑层逻辑都放到应用层和数据库存储过程中,自然转换到领域建模中也存在贫血的问题。

领域对象服务中的领域对象本身就是多个数据表的汇聚,所有对象服务可以解决对象级的事务问题,如订单保存中头和明细的操作严格控制在一个事务里面。但是对于领域服务层的组合服务仍可能存在分布式事务的问题,在这里还是建议基于BASE模式思路进行操作。还有一个方式就是对于组合服务而言,不用直接对原子服务进行组合,而是对原子服务下层的对象级操作API进行组合,这样即方便启用数据库层或逻辑层的事务进行事务控制。

  青春就应该这样绽放   游戏测试:三国时期谁是你最好的兄弟!!   你不得不信的星座秘密

相关 [领域 服务] 推荐:

谈领域服务

- - 人月神话的BLOG
对于跨系统和模块间的SOA服务识别和分析我前面文章谈的比较多,这块的SOA服务重点是实现跨系统和模块的业务交互和协同,而对于领域服务而言则更加关心的是对于单个系统或模块,其应该如何抽象领域对象并将其能力以粗粒度服务方式保留给应用层用. 在领域建模中的整体思路中,我们做两个层面的理解,其一是领域模型层重点是隔离传统的数据表并抽象为领域对象;而对于领域服务层重点是则将应用层和领域模型层解耦,模型层提供的能力是以领域服务的方式暴露到应用层使用的.

再谈领域建模和领域服务

- - 人月神话的BLOG
对于贫血的领域层,主要体现在两个方面,一个是没有领域业务对象的概念(领域模型中的聚合根),一个是没有明确的粗粒度的业务规则逻辑处理层. 在这种情况下,原有的业务逻辑层变化为仅仅是DAL层的一个简单封装或通道,实际的业务处理全部转化到action层或dal层进行了处理,导致无法真正提炼一个业务模块真正应该具备的领域服务能力.

在微服务领域Spring Boot自动伸缩如何实现

- - IT瘾-tuicool
自动伸缩是每个人都想要的,尤其是在微服务领域. 让我们看看如何在基于Spring Boot的应用程序中实现. 我们决定使用 Kubernetes、 Pivotal Cloud Foundry或 HashiCorp's Nomad等工具的一个更重要的原因是为了让系统可以自动伸缩. 当然,这些工具也提供了许多其他有用的功能,在这里,我们只是用它们来实现系统的自动伸缩.

新领域的探索

- Fay - 人月神话的BLOG
在信息技术领域,任何新领域都是已有知识领域,已有技术和研究成果的进一步组合和创新,新领域一分解到底层你会发现全是已有技术,方法和工具. 这些很可能都是我们熟悉的内容,而新领域仅仅是对已有知识和技术的进一步组合,形成一套完整的方法和技术来解决新的问题. 当接触一个新领域的时候,首先是大量的阅读,在一开始没有机会实践的时候,那只有先补充和学习基础的理论,了解新领域的知识体系和结构,了解新领域所涉及到得关键技术.

Viddy:视频领域的Instagram?

- - Tech2IPO
Instagram刚被Facebook以 十亿美元的价格收购,成为照片分享领域的传奇. 与此同时,以视频领域的Instagram而著称的 Viddy在近日也冲上iPhone 免费应用榜首的位置. Business Insider甚至撰文建议 Google收购Viddy,从而在移动视频领域占据先机.

NVIDIA:ARM芯片将将进军PC领域

- Kevin - cnBeta.COM
据国外媒体报道,1993年,黄仁勋创立了英伟达,想要把3D图形技术从硅图超级电脑普及到PC电脑上. 该公司以每六个月推出一款新3D图形芯片的速度打败了无数竞争对手. 18年后的今天,英伟达仍然是硅谷最具创新力的企业之一. 它也是最后一个与微处理器供应商英特尔和AMD分庭抗礼的独立图形芯片制造商.

微内核领域的传说

- jinn - 技术奇异点
IT 业和自然科学领域常说的「传说」一词来源于英文 myth ,是个负面的形容词,更接近「流言」、「谣言」的意思. 如著名的电视节目《流言终结者》(mythblaster). 也经常被翻译成「神话」,如著名的《人月神话》(Man Month Myth). 这篇文章不是要贬低微内核 (micro-kernel) 这个概念本身,而是说人们对这个领域中的很多东西存在不小的误解.

OfficeDrop:办公领域的Dropbox (免费)

- 定风波 - iPad中文报
这是我们刚才上传的一些示例文件. Office Drop的文件夹管理功能. OfficeDrop这个名字很容易让人联想到著名的云端服务Dropbox,不过既然加上了Office这个名字,他当然是专门针对办公人群推出的服务了. 他的功能就是让用户随时随地的获取工作文件,他共支持25种文件格式. OfficeDrop 2.0版客户端本于本周上线,他从一款iPhone版本升级为了通用版应用程序,充分利用了iPad 2的摄像头将纸质文档“扫描”为电子文档.

谈领域驱动的设计

- - 人月神话的BLOG
最近一直在学习领域驱动设计,发现领域驱动设计的核心仍然是传统的面向对象分析设计的思路,但是却可以很好的和现有的组件化架构,分层架构,SOA服务等相关内容更好的融合. 对于传统的EA企业架构分析在分解到最底层的时候,很适合自然过渡到领域驱动设计的思路上来. 另外对于现有的基于NoSQL数据库的信息系统开发,领域驱动设计更是必须具备的系统分析和建模思路.