分层架构设计原则

标签: 架构 设计 原则 | 发表时间:2012-07-05 00:25 | 作者:陈程
出处:http://www.cnblogs.com/

通常一个软件系统都包含不同部分互相交互耦合,我们希望设计能够将系统划分为有意义的各个部件,各个部件能够独立的开发、演进、部署。这时整体性的设计已经无法满足这些挑战,这就需要我们对系统进行合理清晰的划分。通常我们为待开发的系统定义多个层次,每一层完成独立的功能。

设计原则:

1:系统分为多层,每层完成独立的功能,层内部继续细分子模块,每层能够独立演进、部署。分层原则可以基于业务抽象、硬件、变化性等来划分,比如sqlite就是基于业务抽象来进行分层的。实际的框架设计可能同时结合多种维度比如常见的表示层、逻辑层、数据层就结合了业务抽象和变化两个维度。

2:各层的功能基于同层和底层的功能之上,如图所示L1的所有功能基于本层、L2、L3(实际设计中不建议基于跨层功能),也就是说上层只能调用本层和下层的接口。这样的设计避免互相调用导致的结构复杂。

3:各层提供相应的接口与实现分离,对该层的访问只能通过接口进行。通过接口进行访问有效的分离了关注点。外层关注接口,层内部关注接口的实现,实现的修改不会对其它层产生影响。实际应用中可以使用适配器模式来有效的分离接口和实现。假设业务数据可能通过不同的协议栈承载实际数据的传输,不同的协议有不同的实现,我们可以如下设计接口:

上层使用如下数据传输接口:

struct transportDescription
{
int (*receiveData)(void*privateConnectionInfo,void*buffer,int bufferLen,);
int (*sendData)(void *privateConnectionInfo,const void *buffer,int bufferLen);
}

下层提供协议注册接口:

int initializeTransports(transportDescription* pTransInfo);

#ifdef _HTTP_
#define initializeTransports HTTP_initializeTransport
#endif
#ifdef _WSP_
#define initializeTransports WSP_initializeTransport
#endif

上层应用通过调用initializeTransports注册承载协议,上层只需要调用receiveData、sendData 接口进行数据收发,下层协议信息对上层完全透明,通过定义不同的协议宏可以在不同的协议间切换而不影响上层的实现。

4:底层不能依赖高层的功能,这样设计避免了结构的复杂,你不能指望操作系统来调用你的接口吧。但是一些系统的事件确实需要上层应用做出相应的处理,该如何处理呢?这就需要用到观察者模式了,在C语言中一般通过回调机制来实现,这时下层提供接口,上层把实现注册进去。这样底层就可以在不调用上层的接口下控制上层的行为了。

5:数据流是双向交换的,比如在协议栈中数据可以在相邻的层次之间交换的,下层到上次的数据流可以有多种方式比如消息机制、回调机制等。消息机制有利于分布式部署并且是一种松耦合的形式,只要接收双方定义了消息格式即可,不再需要依赖具体的接口。

 

分层架构通过对关注点的分离有利于分化系统的复杂性,提高系统的可扩展和可维护性,但在分层架构中为了获取底层的功能可能需要进行多个层次的传递,不可避免的导致性能的下降。为了保持架构的稳定在开发中增加功能往往需要在各层都要添加相应的代码。

 

 

 

本文链接

相关 [架构 设计 原则] 推荐:

分层架构设计原则

- - 博客园_首页
通常一个软件系统都包含不同部分互相交互耦合,我们希望设计能够将系统划分为有意义的各个部件,各个部件能够独立的开发、演进、部署. 这时整体性的设计已经无法满足这些挑战,这就需要我们对系统进行合理清晰的划分. 通常我们为待开发的系统定义多个层次,每一层完成独立的功能. 1:系统分为多层,每层完成独立的功能,层内部继续细分子模块,每层能够独立演进、部署.

实战解析Android架构设计原则

- - 移动开发 - ITeye博客
关注微信号:javalearns   随时随地学Java. 经过一段时间收集了大量反馈意见后,我认为应该来说说这个话题了. 我会在这里给出我认为构建现代移动应用(Android)的好方法,这会是另一番体味. 开始之前,假设你已经阅读过我之前撰写的文章“ Architecting Android…The clean way ?”.

架构设计的三个原则 | 张逸说

- -
在进行架构设计时,我认为需要遵循如下原则:. 一致性是软件架构质量原则的根基,遵循一致原则的软件架构可以有效地保证整个架构解决方案的清晰直接,降低了解决方案的复杂度. 尤其对于一个大规模系统,往往需要多个团队共同开发完成,如果不遵循一致原则,就会导致整个平台的建设缺乏完整性和规范性,各个子系统各自为政,业务功能重复开发,技术实现五花八门,服务集成复杂低效,信息冗余制造出知识壁垒.

Android设计原则

- - 所有文章 - UCD大社区
译者按: 在 iOS HIG已经强大经典了N年之后,Android终于推出了一套比较系统的 HIG(大概是为了配合Android 4.0 Ice Cream Sandwich). 仔细比较两套HIG的“设计原则”部分,发现完全是截然不同的两种风格. iOS HIG走的是更专业型的路线,描述严谨且有不少的专业词汇(比如Metaphors、Consistency之类的).

设计指导原则

- - 企业架构 - ITeye博客
避免在循环内部new一些没有必要每次都new的对象. 所有与IO相关的操作,都需要考虑性能问题,一般采取的措施是连接池,缓存,减少调用次数,合并请求. 每个业务都要分析整个请求链路,找到瓶颈,通过压测的方式确认问题及验证解决方案. 根据业务情况,使用异步化和最终一致性. CPU,内存,网络IO,磁盘IO这些瓶颈,需要知道在合适的场景牺牲什么换取什么.

MySql 之表设计原则

- - 互联网 - ITeye博客
1) 不应该针对整个系统进行数据库设计,而应该根据系统架构中的组件划分,针对每个组件所处理的业务进行组件单元的数据库设计;不同组件间所对应的数据库表之 间的关联应尽可能减少,如果不同组件间的表需要外键关联也尽量不要创建外键关联,而只是记录关联表的一个主键,确保组件对应的表之间的独立性,为系统或表 结构的重构提供可能性.

设计模式和设计原则

- - 编程 - 编程语言 - ITeye博客
26.1  设计模式和设计原则. 26.1.1  设计模式和设计原则的关系. 面向对象的分析设计有很多原则,这些原则大都从思想层面,给我们指出了面向对象分析设计的正确方向,是我们进行面向对象分析设计应该尽力遵守的准则.        而设计模式已经是针对某个场景下某些问题的某个解决方案. 也就是说这些设计原则是思想上的指导,而设计模式是实现上的手段,因此设计模式也是应该遵守这些原则的,换句话说,设计模式就是这些设计原则的一些具体体现.

软件架构设计

- - 企业架构 - ITeye博客
软件架构设计尚没有万灵的方法论支持,还是个非常新兴的行业,给出个人理解的行业软件架构设计过程,受个人水平有限,仅供参考:. 1.业务分析:针对目标行业的业务战略、蓝图、业务功能及流程进行分析,提出其中部分功能可以使用信息化进行处理,通过分析可以得出信息化要解决的问题. 2.解决方案设计:根据业务战略,形成行业信息化解决方案.

架构设计-逻辑层

- - 人月神话的BLOG
知乎看到一个问题,也是当前在软件设计开发中普遍存在的一个问题,如下:. 现在要开发一个业务逻辑比较复杂的项目,但是在网上看了设计模式的思想后感觉自己以前写的东西扩展性都不好,接口定义也不合适,都是一个实体类一个接口,项目施工也感觉不合理,感觉项目施工中应该先集中定义好接口,并完成业务逻辑,然后在具体实现接口,不知道这样想是不是正确.

秒杀架构设计

- - IT瘾-dev
最近在部门内部分享了原来在电商业务做秒杀活动的整体思路,大家对这次分享反馈还不错,所以我就简单整理了一下,分享给大家参考参考. 通俗一点讲就是网络商家为促销等目的组织的网上限时抢购活动. 比如说京东秒杀,就是一种定时定量秒杀,在规定的时间内,无论商品是否秒杀完毕,该场次的秒杀活动都会结束. 这种秒杀,对时间不是特别严格,只要下手快点,秒中的概率还是比较大的.