文档章节

基于业务模块组件的系统架构

apsaras
 apsaras
发布于 2016/06/20 09:41
字数 2201
阅读 91
收藏 1

以前写过一篇《基于抽象的分层结构》,这里补充一篇《基于业务模块组件的系统架构》
一些内容在《项目笔记:dao,web,模块边界以及Model分类》以及《模块的接口设计》随笔中已经提到,这里补充总结一下。

任何一个有一定规模系统,通常会把系统做一定分解降低分析设计开发的难度,模块划分是一个比较常见的方式。
而在模块的划分及其分析设计的实践中,包括了两种层次的边界。第一是交互行为层次,第二是对象层次。

首先说交互行为。
模块和模块的交互接口最为重要,通常我们认为这些接口应该通用稳定,然而如何设计每个模块对外提供的接口却是一个不易的问题。

集成的两种基本实现方式:
1. API方式
这是常见的实践方式。即每个模块公开数量不多的接口类(但拥有较多的接口方法)以及接口参数(都是普通的VO),每个接口的设计和实现都有该模块成员维护;实践中:这些接口都独立打包,形成多(模块)对一(接口)的依赖关系,方便编译。
这样的好处是:接口边界清晰,开发编译依赖比较简单。
然而实践中极有可能出现两种状况:接口维护失控或者过严而死板(而影响开发)。接口失控是因为接口的维护太过随意,因为A模块的需要就轻易在B模块中添加一个接口(方法),导致该接口(方法)非独立性(基本上只给模块A的这个功能点使用),或者是接口的控制过严,导致或者工作效率不高,或者接口的易用性不好。
原因在于:接口是两个模块间的耦合,而发生的种种问题在于模块耦合太过紧密;同时实践中,把模块对外提供的接口,与模块需要实现的外部模块的集成混为一谈;换句话说,A模块需要集成的语义,和B模块提供接口的语义存在差距。
这样的实践优点:开发管理控制成本较低,模块编译依赖简单,模块物理边界明确。

2. Adapter方式
这种的实践可以一定程度上解决API方式面临的问题:根据指导原则——为了降低耦合只有在中间加一层;即不轻易为模块设计对外提供的接口(方法),除非是通过重构得来的;模块对外提供两种类:一个是需要外部模块实现的接口(接口设计从本模块需要出发,当然每个接口尽管是为某个功能点服务,但也要注意其在模块内通用性);另一个是其它模块要求本模块实现的接口的实现类(这块物理上独立打包,独立于模块之外)。
即:A模块拥有一些需要B模块实现的接口(A模块对B模块的要求),而B模块中也有要求A模块实现的接口,因而A有这些接口的实现类。
处于编译依赖的考虑,已有的实践是把处理接口适配的代码维护在模块外的,就是所谓的集成模块,这样编译上就形成了1(接口实现)对n(模块)的依赖关系。模块的边界在这里模糊了,当然在这之外模块的边界是很清晰的。
这种实践方式的好处在于:模块的接口就多了一层隔离降低了耦合,把接口的通用性和接口的适应性分离,又明确了模块的边界,使得接口在日后的优化和调整有了缓冲。
这样的实践和API实践的不同之处在于:接口的设计权利一分为二,需求方拥有了其应该有的权利,并且这个权利与提供方没有冲突(旧的模式不行,一旦供应方改变了接口,就立刻导致编译问题)。

两种方式的对比:
1. 采用API方式集成,代价在于维护API本身,API面对众多的客户端,其面临的设计维护成本较高,同时实施成本高;
2. 采用Adapter方式集成,由于没有维护API,缺乏可复用接口,但可以做到为每个客户端自由定制,其设计维护成本较低,实施上成本较高;

 集成的演进方式:
1. 采用事件模式。
这也是完成交互处理的模式。通常事件模式在业务行为上也可以完成和接口相互的功能,不过由于其在接口签名上无法明确提供其业务含义,建议谨慎应用。对于产品化项目,项目开始可以应用事件处理机制,在成熟时提取为更具体的接口。
 事件模式中,Event的监听类也面临着模块的边界问题。已知的成熟开源项目都在事件源中暴露的模块内部对象,方便开发者使用。
 可以说这种方式的是Adapter方式的演进;
 
2. 采用框架回调方式
工作流和页面流也负责集成不同的模块.不过因为工作流和页面流框架都维护独立的数据对象共享池,因而在这个层面上,模块间直接的交互并不存在。这种集成上的优势,演化成通过ESB等集成框架完成.
 这种方式是API方式的演进,但是把调用点以及调用方独立出来,成为框架的一部分。

现在说说对象一级的边界集成。
在保险中,benefit对象会关联一个product对象,不过product对象是是属于产品模块而非保单模块,对于保单模块只关心id而并不使用对象,但在RMS或者FMS或者UIC这样的集成环境却是需要product对象的。我们要采用代码生成的方式,在benefit对象上加一个annotation,比如Integration的annotation标识,使用AspectJ在编译上enhancement生成的class,使得benefit对象在集成环境上可以拿到product对象,这算是一个集成方面。

组件化管理
组件化管理包含两个含义:
1. 组件访问控制,依赖管理以及服务注册;
现有的访问控制的办法,只能通过代码提交时或者编译发布时检查,但我们更期望支持运行时的能力,避免外部组件访问组件未申明公开的内部结构和程序;同时维护方式应该简单方便,成本低。
目前的组件依赖管理几乎没有,尤其是基于版本的依赖;而在实践中,依赖维护管理尤其是多版本的通常花费大量的成本。
2. 组件依赖的绑定以及失效(故障)的隔离;
我们希望能够为每个组件提供一个保护区域,当其依赖的一个组件因为种种原因(软件错误的或者软件升级)失效时,系统至少应该提供一种fail-fast机制,包括如下能力:
A.故障即停(Halt on failure)——当一个组件出错时,应当立即停止下来,而不是继续执行可能不正确的操作;
B.故障曝光性质(Failure status property)——当一个组件发生故障时,系统中的其他组件应该得到通知,故障的原因必须交代清楚;
同时,我们希望该组件,如果可能它应该可以继续运行。完成这样的目标需要很多的工作,但首先依赖于系统fail-fast能力,同时在故障消除服务恢复后,系统能够提供相应的通知,并控制恢复的顺序。

已知的支撑框架:SCA和OSGi
1. SCA考虑的是异构异步环境,OSGi考虑同构同步环境;
2. OSGi规定了容器如何管理组件,组件依赖(版本)管理,组件边界保护以及组件服务依赖运行时绑定策略和权限控制;SCA对此没有涉及;
3. SCA考虑的如何暴露服务,设计时客户端如何使用服务;OSGi考虑的更加完善;

本文转载自:http://jportal.iteye.com/blog/380735

apsaras
粉丝 8
博文 90
码字总数 0
作品 0
海淀
架构师
私信 提问
BPMX流程管理平台

BPMX 简介 BPMX 是基于JEE开源、轻量级的企业流程业务开发平台,基于代码重用、组件重用、业务逻辑重用、组装重用,结合在线流程设计器 、在线业务表单设计工具及代码逻辑生成器, 将开发人员...

Activiti-保
2014/09/09
2.4K
0
利用Database2Sharp生成的EnterpriseLibrary架构的特点

框架的主要特点: 1)基于N层架构分层思想,各层边界清晰,可维护性更好。 2)基于最为广泛接受的RBAC(Role Based Access Control )的权限模型,控制更强、更合理。 3)遵循省移动公司统一UI样...

walb呀
2017/12/04
0
0
《软件架构模式》-第四章 微服务框架模式(下)

原文链接 译者:克里斯托刘 《软件架构模式》-第四章 微服务框架模式(下) 避免依赖和编排 设计微服务架构的一个主要难度是为服务组件选择正确的粗细粒度。如果服务组件设计的太粗糙,就彰显...

CrystalLiu
2018/01/10
0
0
某局二期项目架构设计及开发

1.完成整个项目的架构设计 2.项目核心系统或者模块详细设计,比如:分库分表的数据模型、采集数据的hbase数据模型、系统间交互、数据采集服务器 3.基于使用到的开源组件的易用性封装 4.数据采...

CeciliaGG
2017/04/10
4
0
某局二期数据服务

1.完成整个项目的架构设计 2.项目核心系统或者模块详细设计,比如:分库分表的数据模型、采集数据的hbase数据模型、系统间交互、数据采集服务器 3.基于使用到的开源组件的易用性封装 4.数据采...

CeciliaGG
2017/01/16
2
0

没有更多内容

加载失败,请刷新页面

加载更多

OSChina 周日乱弹 —— 我,小小编辑,食人族酋长

Osc乱弹歌单(2019)请戳(这里) 【今日歌曲】 @宇辰OSC :分享娃娃的单曲《飘洋过海来看你》: #今日歌曲推荐# 《飘洋过海来看你》- 娃娃 手机党少年们想听歌,请使劲儿戳(这里) @宇辰OSC...

小小编辑
今天
401
10
MongoDB系列-- SpringBoot 中对 MongoDB 的 基本操作

SpringBoot 中对 MongoDB 的 基本操作 Database 库的创建 首先 在MongoDB 操作客户端 Robo 3T 中 创建数据库: 增加用户User: 创建 Collections 集合(类似mysql 中的 表): 后面我们大部分都...

TcWong
今天
4
0
spring cloud

一、从面试题入手 1.1、什么事微服务 1.2、微服务之间如何独立通讯的 1.3、springCloud和Dubbo有哪些区别 1.通信机制:DUbbo基于RPC远程过程调用;微服务cloud基于http restFUL API 1.4、spr...

榴莲黑芝麻糊
今天
3
0
Executor线程池原理与源码解读

线程池为线程生命周期的开销和资源不足问题提供了解决方 案。通过对多个任务重用线程,线程创建的开销被分摊到了多个任务上。 线程实现方式 Thread、Runnable、Callable //实现Runnable接口的...

小强的进阶之路
昨天
6
0
maven 环境隔离

解决问题 即 在 resource 文件夹下面 ,新增对应的资源配置文件夹,对应 开发,测试,生产的不同的配置内容 <resources> <resource> <directory>src/main/resources.${deplo......

之渊
昨天
8
0

没有更多内容

加载失败,请刷新页面

加载更多

返回顶部
顶部