BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

SOA的依赖原则

| 作者 Mark Little 关注 14 他的粉丝 ,译者 李彬 关注 1 他的粉丝 发布于 2013年8月2日. 估计阅读时间: 4 分钟 | QCon上海2018 关注大数据平台技术选型、搭建、系统迁移和优化的经验。

在去年的QCon上,Ganesh Prasad分享了他对SOA的看法。今年早些时候,他在一篇文章里对其中部分内容作了展开,阐述了在他是怎样将SOA思想视作一种面向依赖思想的:

SOA是一门对系统之间的依赖进行分析和管理的科学,“管理依赖”意味着消除不必要的依赖,并将合规依赖转变为易于理解的契约。

为了辅助说明自己的观点,他给出了下面这幅图:

Ganesh表示:

在业务层,对依赖的聚焦迫使我们将流程合理化并进行精简。业务流程需要能够追溯到组织机构的愿景(关于“乌托邦”的理念)、组织的任务(实现“乌托邦”的战略)和为执行那些战略所需的广泛功能(产品管理、工程、市场、销售等等)[……]在应用层,我们尝试对操作进行分组。注意业务层已经将操作的运行时分组定义为流程,而在应用层,我们需要更加静态地对其进行分组。哪些操作是一类的,哪些不是?这就是应用层需要考虑的依赖问题。然而,只有在下面的信息层才能找到这些问题的答案,因为只有当操作共享同一份数据模型的时候他们才是“一类的”。因此,数据模型可以分为两组,分别是“外部”和“内部”。任何系统的“内部”数据模型又被称作“领域数据模型”,它们将永远不会对其他系统可见。与之相对应,系统的“外部”数据模型被称为“接口数据模型”,它们永远对外暴露并与其他系统分享。

最近,Ganesh有机会将这些理念变为现实,并参照此方法观看实际工作中的使用情况。对于每个失败的场景,Ganesh认为其罪魁祸首都可以归咎于违反了一个或多个依赖原则。因此,他坚信如果组织机构能够遵循这些规则,那么最终将能够“实现SOA”。当然,我们拥有多年以来的许多其他例子——关于SOA的失败和成功之处,以及相应的为了让SOA成功而遵循原则与规则的尝试。Ganesh概括出的原则,可以根据操作的层次分为四类:

业务层:

(1)可追踪性——实行核心治理,“确保每件完成的事情都与组织机构的愿景有关”。

(2)极简主义——挑战假设。

(3)领域洞察——理解业务的本性,“从基本原则重新构想业务”。

应用层:

(4)内聚与耦合——“那些属于一类的应该归到一起,并且在不同系统间仅保留最小限度的联系。”

(5)实施与曝光——“共用领域数据模型和业务逻辑的操作组都会转化为产品,而共用接口数据模型的都会转化为服务。”

(6)变体与版本——“识别出每个逻辑操作的多重并行类型,建立一种方法来支持其逻辑和接口的不断变更”。

信息(数据)层:

(7)内部与外部——“区分接口数据模型与领域数据模型”。

(8)内容与上下文——“将接口数据模型的核心数据元素与限定元素分离”。

(9)抽象与具体——“创建同时适用于内容和上下文元素的数据类型的层次结构”。

技术层:

(10)捆绑依赖——“在实现业务逻辑的过程中,避免在无关的组件之间引入新的依赖”。

(11)后期绑定——“推迟不可避免的依赖,直到最后责任点”。

(12)完成工作的合适工具——“使用最合适的机制来实现逻辑”。

对用于SOA的面向依赖思想的原则和理念,各位读者怎么看?它们是否已经对你曾经参与的某个SOA项目产生了帮助?现在你是否会考虑使用它们,或是基于自己的经验对其进行修订?

查看英文原文:Dependency Principles for SOA

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我
社区评论

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT