聊聊架构-模块化

什么是模块化?

 

模块化是指解决一个复杂问题时,自上而下逐层把系统划分成若干模块的过程。

 

为什么需要模块化?

模块化的目的是为了降低程序的整体复杂度,使程序设计、调试和维护等简单化。各个模块可独立工作,即便单模块出现故障,也不影响整个系统工作。模块化具有三个特性:相互独立,可替换,通用。比如车载收音机就是模块化设计,收音机和汽车里的其他模块相互独立,收音机坏了不会影响车上的其他功能,具备独立性。因为汽车预留了接口,可以随意的将收音机替换成CD机和DVD机等,具备可替换性。车载收音机从汽车里取出来后,拿到其他车或者其他地方也是可以使用的,具备通用型。

如何实现模块化?

 

模块化的表现形式可以是多个二方包或者一个Maven工程的子模块。系统中的公共组件可以抽取出来形成一个二方包,提供给更多的系统使用,比如业务系统里的任务框架,数据库锁组件和配置管理等。

 

如何划分模块?

  • 基于水平切分。把一个系统按照业务类型进行水平切分成多个模块,比如权限管理模块,用户管理模块,各种业务模块等。
  • 基于垂直切分。把一个系统按照系统层次进行垂直切分成多个模块,如DAO层,SERVICE层,业务逻辑层。
  • 基于单一职责。将代码按照职责抽象出来形成一个一个的模块。将系统中同一职责的代码放在一个模块里。比如我们开发的系统要对接多个渠道的数据,每个渠道的对接方式和数据解析方式不一样,为避免不同渠道代码的相互影响,我们把各个渠道的代码放在各自的模块里。
  • 基于易变和不易变。将不易变的代码抽象到一个模块里,比如系统的比较通用的功能。将易变的代码放在另外一个或多个模块里,比如业务逻辑。因为易变的代码经常修改,会很不稳定,分开之后易变代码在修改时候,不会将BUG传染给不变的代码。

易变和不易变?

根据代码的易变程度,将不变和变化的功能隔离,可以让代码更加稳定,减少代码的修改量,从而降低维护成本。从几个层面逐渐入手:

  1. 系统分层:J2EE系统一般都划分成页面展现层,业务逻辑层和持久层。业务逻辑层容易变,而持久层变化小。对外提供服务系统分层是服务层,实现层和持久层,一般也是实现层不稳定需要经常修改,但是修改不会波及到持久层和服务层。将系统分层后,底层要更加稳定,可以新增接口或代码,但是尽量减少修改代码,因为底层一旦出错,影响面会非常广。系统间的分层也同样是需要底层系统更稳定。
  2. 代码分隔:代码上分为接口,抽象类和实现类。抽象类和接口要做到充分的抽象,从而减少修改。比如接口要符合单一原则,避免接口修改。比如Java的Closeable接口里只有一个close方法,指责非常单一,所以无论未来有什么场景,基本不会修改这个接口。如果你的接口里有很多其他职责的方法,一旦一个方法修改,很多实现类就必须跟着修改。
  3. 转载自 并发编程网 - ifeve.com
时间: 2024-09-17 10:54:11

聊聊架构-模块化的相关文章

聊聊架构

(最近我会写一些我对架构的理解和思考,本篇是第一篇,欢迎交流) 什么是系统架构? 从字面上理解,系统架构是系统的框架结构,是系统进行抽象之后的一个草图.它包含了系统中各个抽象组件的协作方式. 为什么需要架构? 好的架构能够降低系统的创造和维护成本,特别是维护成本.一个系统的创造成本低,而维护的成本大,特别是互联网应用,一般情况下把一个系统搞上线只需要一个月,但是有的系统搞下线缺需要几个月,而维护则需要数年.好的设计师不会在系统上线后对系统进行大的修改,从而减少系统的维护成本. 如果区分创造和维护

桌面虚拟化的架构模块化综述

很多客户在提及桌面虚拟化的时候,都会问到很多问题,感觉桌面虚拟化是个很新颖的东西,有点复杂,如果我们可以将其模 块化,这样对我们的客户也是一个很大的帮助. 许多公司都找寻找可以更好管理桌面的解决方案,传统的购买硬件,做好镜像,维护,淘汰,重新进入一个新的循环.而桌面虚拟 化带来一种全新的解决方案,可以交付给用户一台安全度高,可信赖,性能不差于传统PC的电脑. 而我们在向我们的客户解释桌面虚拟化的技术架构时,可以将其拆分为以下模块,客户才能更好的接受. 本文以Citrix XenDesktop为例

嘿!架构师,你写不写代码呀?

概要: 1.架构师是神马狮,代码是什么马 2.架构师的成长之路 3.架构师是使用代码作画的大狮 4.本期"小狮子"奖 架构师是什么狮,代码是什么马 记得那天是这样的,总导演(右导)一抛出话题,群内雄狮们可炸开了锅: 狮子郭:架构师应该写代码,架构师需验证自己架构上想法的可行性- 狮子肖:架构师必须得做到了解现状,方案与实际相符,别和猿类离得太远... 狮子P:架构最早是源自建筑,没见过建筑架构师码过砖. 狮子木:仰望星空,脚踏大地. 大伙交流得很high,本狮却觉得心底空闹闹的,我们在

我真的只是标题党:以架构的思维看世界

为什么要聊聊架构? 又到一年财年底,又到了各架构师们交配.no,交流的季节.各位蠢蠢欲动,开始为新年的规划发展开始忙活.最近一段时间,本人也连续给多个新系统做了技术架构,也看了很多别人做的架构.老系统演进架构. 随着经历和经验的不断增加,貌似在画图工程师这条路上也有了一定的进步,跨入了画图高级工程师的行列.结合"知行合一"的战略指导方针,在"格物致知"到一定程度后,也尝试通过自己的知识迁移能力.抽象总结能力,来寻找画图这件事里蕴含的"道".So,

在首席架构师眼里,架构的本质是……

目前讨论架构实操(术)的文章较多,讨论架构理念(道)的较少,本文基于作者在大型电商系统架构方面的一些实践和思考,和大家聊聊架构理念性的东西,希望能够抛砖引玉,推进大家对架构的认识. 什么是道,什么是术?道是事物发展的本质规律,术是事物发展的具体途径.规律只有一个,途径很多,条条大路通罗马,罗马是道,大路是术.道为本,术为途,如果事先知道罗马在哪里,那么遍地是路,路路相通.架构也是如此,如果能领悟架构的本质,就不会拘泥于现有的实践和理论框框,而以最直接的方式解决问题,无招胜有招.本文的内容包括架构

作为首席架构师,我是如何选择并落地架构方案的?

本文系转载.转载自:http://mt.sohu.com/20160516/n449639733.shtml   如何针对当前需求,选择合适的应用架构,如何面向未来,保证架构平滑过渡,这个是软件开发者,特别是架构师,都需要深入思考的问题. 本文首发于InfoQ垂直号「聊聊架构」,ID:archtime 无架构,不系统,架构是大型系统的关键.从形上看,架构是系统的骨架,支撑和链接各个部分:从神上看,架构是系统的灵魂,深刻体现业务本质. 架构可细分为业务架构.应用架构.技术架构,业务架构是战略,应用

架构的本质(转)

目前讨论架构实操(术)的文章较多,讨论架构理念(道)的较少,本文基于作者在大型电商系统架构方面的一些实践和思考,和大家聊聊架构理念性的东西,希望能够抛砖引玉,推进大家对架构的认识. 什么是道,什么是术?道是事物发展的本质规律,术是事物发展的具体途径.规律只有一个,途径很多,条条大路通罗马,罗马是道,大路是术.道为本,术为途,如果事先知道罗马在哪里,那么遍地是路,路路相通.架构也是如此,如果能领悟架构的本质,就不会拘泥于现有的实践和理论框框,而以最直接的方式解决问题,无招胜有招.本文的内容包括架构

阿里9年,我总结的前端架构演进3大阶段及团队管理心法

技术人生就是在不断地修行,每个人都有每个人的功课,每个人也有每个人的精彩.你也许刚上路,又或许踽踽独行了很久,听听别人的故事没准也能帮助自己的成长.在阿里修行的9年,他学会了这些. 少年励志,初入技术圈 我生在一个文化气息浓厚的家庭,这让我从小就对艺术有了一种懵懂的向往.第一次接触到计算机时,我就明白自己会在这个领域玩下去:第一次接触到互联网时,我就坚定了将其作为事业,把自己的黄金年龄投入其中的信念.文化气息的熏陶和坚定的信念,使得我踏上了寻找将美好的设计感和互联网技术相结合的长路上. 2004

架构之坑系列1:重构中的过度设计与高可用银弹

这是一个坑系列,会说一些在系统设计.系统架构上的坑,这些都是我想到哪说到哪,有像这篇一样比较宏观的坑,后面的文章也会有到具体技术细节的(比如某个函数,某个系统调用)坑.总之,到处都是坑,这些坑有些是我经历过的,有些是听说的,你也可以留言说说你遇到的坑.   第一部分,我们从重构这个场景来看看系统架构的设计中过度设计这个坑.首先,我们这里说的重构,和<重构:改善既有代码的设计>这本书中的重构不太一样,这是本好书,他主要说的是代码级别的重构,这种重构是需要在编码的时候时时刻刻进行的,更多的是一种编