要设计良好的架构,必须做到关注点分离,这样可以产生高内聚、低耦合的系统,这是美丽架构的终极原则。
什么是架构? 每个人可能都有自己对架构的定义。我比较喜欢的定义是:“架构是系统的组成部件及其之间的相互关系。”根据观察者的视角不同,架构又可以分为业务架构和技术架构。一般来说, 功能性需求会对业务架构产生影响, 而非功能性需求会对技术架构产生影响。
例如:“注册用户可以向自己的相册上传图片,并与好友分享”。这是一项功能性需求。它告诉了我们在系统的业务架构中,会出现“注册用户”“相册”、“图片”、“好友”等组成部件,它们之间存在着相互关系。而“系统可以支持10万并发用户,并在需要时可以方便地伸缩,扩展到支持100万到1000万的并发用户”,则是一项非功能性需求。它告诉了我们系统在性能、负载、吞吐量、可伸缩性方面的特性,目标系统的架构必须对这些特性提供支持。
架构体现的是对复杂系统的分解设计。而如何进行分解,则是软件设计领域永恒的话题。实际上,架构体现的是关注点分离的原则和方法。经典的三层架构,由展现层、业务逻辑层和持久层构成;其中体现了我们对用户界面、业务逻辑和数据持久的关注点分离。这种架构从命令行时代的软件就开始有了,直到最新的AJAX 加RESTful的Web 应用架构中仍然可以看到它,因为这种关注点的分离在这些应用中是必要的。
我们可以在Web 应用中不采用三层架构,也就是不进行这种分离。我们可以在JSP/ASP/PHP中混合用户界面、业务逻辑和数据持久层。但是这样的代码是难以维护的,难以适应大规模项目开发,难以适应将来的变化。关注点不分离的代码为阅读和理解制造了更多的障碍。用户界面、业务逻辑和数据持久三者的分离,让它们能够相对独立地进行变化,比如实现新的用户界面方式、改变业务逻辑和采用新的数据持久机制。
依赖注入的架构方式因Spring、Guice 等框架而被广大Java 程序员所熟悉,进而扩展到.NET等其他语言和平台,它也体现了关注点的分离。
首先,依赖注入体现了“做什么”和“怎么做”的关注点分离。学过C语言的程序员都知道,这种关注点的分离有着悠久的历史,它表现为.h文件和.c文件,一个规定函数原型,一个规定函数实现。这种关注点分离后来还在面向对象的设计中表现为“针对接口设计”,于是我们在依赖注入的架构方式中,看到了许多的接口,以及接口的不同实现。组件的使用者关注组件做什么,组件的实现者关注组件怎么做。其次,依赖注入体现了对实例生命周期(特别是实例创建)和组件装配的关注点分离。我们可以集中指定对象创建的方式,方便灵活地改变系统的装配方式。通过这样的关注点分离,依赖注入的架构让系统变得更灵活,让组件的实例化和组装方式集中在系统的一个局部来确定,而不是分散在系统各处。
《彩色UML建模》一书中提出了4种领域无关的架构型,体现了业务流程、业务事件、参与者角色、具体参与者、分类分组的关注点分离。它研究的是业务架构,告诉我们如何设计一些组件来体现业务逻辑。
以ATM机取款为例,它包含一个业务流程,由身份认证、取款、打印凭据等事件组成。单独来看取款这个事件,彩色UML方法会在模型中体现出“取款(时刻/ 时段)”、“账户(物品)”、“信用卡(物品)”、“ATM机/ 取款柜台(地点)”等组件。这样的关注点分离,使得这一组取款组件可以从业务流程中独立出来,所以它也可以参与其他业务流程,如柜台取款。
REST是一种Web应用架构风格,它的主要特点包括:
资源是由URI来指定。
对资源的操作包括获取、创建、修改和删除资源,这些操作正好对应HTTP协议提供的GET、POST、PUT和DELETE方法。
通过操作资源的表形来操作资源。
可以通过内容协商机制来取得同一资源的不同物理表现形式,可以是XML、HTML、JSON或其他格式,这取决于请求者是机器还是人,是消费Web服务的客户软件还是Web浏览器。
在REST架构风格中,体现了对资源命名、请求处理和资源物理表现形式的关注点分离。
由于实现了这些关注点分离,REST有下面这些好处:
可以利用缓存Cache来提高响应速度。
通讯本身的无状态性可以让不同服务器处理一系列请求中的不同请求,提高服务器的扩展性。
浏览器即可作为客户端,简化软件需求。
相对与其他叠加在HTTP协议之上的机制,REST的软件依赖性更小。
不需要额外的资源发现机制。
在软件技术演进中的长期的兼容性更好。
AOP(面向方面编程)也是关注点分离思想的一种体现。记日志是说明AOP 思想的一个常用例子。当我们在业务代码中嵌入很多日志代码时,业务代码的可读性就下降了,因为业务逻辑和日志是两个不同的关注点。通过AOP技术来分离这两个关注点,就提高了代码的可读性和可维护性。
Ivar Jacobson在他的《Aspect-Oriented Software Developmentwith Use Case》一书中, 提出了AOP思想与用例技术结合的方法。例如,在“用户利用电话系统通话”和“对用户的通话计费”这两个用例中,我们的关注点是不同的。但是如果不采用AOP的方法,实现代码中必然将这两个关注点的代码编织在一起。如果对一个业务过程有许多不同的关注点,代码就变得复杂而难读了。于是Ivar提出,分离两个关注点, 再利用AOP的技术将它们最终编织在一起。这样,我们就能单独面对一个方面的关注点。
AOP技术用一种特别的方式实现了关注点分离,它的好处是明显的,但也有一些不足。比如对于编织后的系统除错,会因为执行流的跳转而变得比较复杂。这时候,我们需要通过一些其他技术来弥补,例如回归测试。我们在实现了“用户利用电话系统通话”后,写一个回归测试将工作成果确定下来。在我们实现之后的业务关注点时,经常跑这个回归测试,确保不会因为新的编织而在系统中引入缺陷。
EJB技术虽然在早期受到了一些诟病,但是它的架构设计总体上仍然是非常漂亮的。EJB体现了分布式计算、持久、实例化、缓冲、事务、安全性等关注点的分离。
Google提出的MapReduce技术是一种新的集群计算思想, 它体现了分布式并行计算的关注点分离。Apache 的Hadoop项目就是这种技术的一个实现。通过这种技术,实现了对大规模分布式系统的性能、可伸缩性、可靠性的关注点分离。程序员可以在不了解太多分布式计算细节的情况下,开发出大规模分布计算程序。
关注点分离带来的是高内聚、低耦合的系统,这是美丽架构的终极原则。在实践中,这种关注点分离可以是一开始就设计好的,也可以是逐渐形成的。如果是逐渐形成的,那就是所谓的演进式架构。例如,我们可以先不实现持久机制,在项目进行到一定阶段再来实现。或者在以后方便地更换持久机制。
我们在系统分析时确定系统都有哪些关注点,然后设计一个架构来支持这些关注点的分离,最终将得到在相同的关注点上高内聚,在不同的关注点上低耦合的设计。
(本文来自《程序员》杂志0908期
分享到:
相关推荐
关注点分离是面向服务的架构的核心原则。令人遗憾的是,该原则在实现SOA服务时常常起不到作用。我们通常会看到带有多个关注点(如安全、事务 管理)的巨大的实现类,使用业务逻辑记录所有混合在一起的关注点。使用...
通过职责划分来分离关注点。面向对象设计的关键所在,就是职责的识别和分配。
又如REST架构风格,体现了对资源命名、请求处理和资源物理表现形式的关注点分离。资源的名称与请求资源时服务器的处理方式无关,请求者无需知道服务器端采取的技术,并且请求者本来就不关心服务器端的处理技术。资源...
火龙果软件工程技术中心 关注点分离(separationofconcerns)是面向服务的架构(Service-OrientedArchitectures,SOA)的核心原则。令人遗憾的是,该原则在实现SOA服务时常常起不到作用。我们通常会看到带有多个关注点...
作为基本的系统化计算思维原则,关注点分离体现在问题求解、算法设计、软件设计、软件架构描述、软件开发过程等诸多方面。简要归纳了软件和计算的本质特点;重点分析关注点分离作为重要的方法论原则在软件工程中的主要...
微软企业级架构设计,分层设计,各层说明,分离关注点
在体系结构的设计、演化和重用过程中涉及众多的关注点,而且它们之间存在着复杂的关系,然而目前还缺乏有效的对这些关注点及其关系进行描述和分析的方法.针对这一问题,在系统收集并显式标识各种体系结构关注点及其关系...
架构之美体现了关注点的分离与结合。在软件设计中,设计师需要考虑多方面的关注点。漂亮的架构设计让这些关注点尽可能分离,然后以最简单的机制结合在一起,从而得到高内聚、低耦合的系统.
3.1 3分离关注点 3.2 面向对象设计 3.2.1 面向对象基本设计原则 3.2.2 高级原则 3.3 从原则到模式 3.3.1 模式究竟是什么 3.3.2 模式vs.惯用法 3.3.3 依赖注入 3.4 在设计时就考虑需求 3.4.1 可测试性 3.4.2 安全性 ...
3.1 3分离关注点 3.2 面向对象设计 3.2.1 面向对象基本设计原则 3.2.2 高级原则 3.3 从原则到模式 3.3.1 模式究竟是什么 3.3.2 模式vs.惯用法 3.3.3 依赖注入 3.4 在设计时就考虑需求 3.4.1 可...
人们在生活和工作中发现美并创造美,软件开发和架构设计也不例外。架构之美体现了关注点的分离与结合。在软件设计中,设计师需要考虑多方面的关注点。架构之美这本书完美的体现了这点。
38.20 PersistentObject和关注分离 38.21 未决问题 第39章 架构的文档化:UML和N+1视图模型 39.1 SAD和架构视图 39.2 表示法:SAD的结构 39.3 示例:NextGen POS的SAD 39.4 示例:Jakarta Struts 的SAD 39.5 ...
该样板为UI和业务逻辑之间的关注点分离提供了用于构建可靠的跨平台移动应用程序的优化架构。 它已完全记录在案,因此可以理解和使用应用程序中的每一段代码。 If you love this boilerplate, give us a star, you ...
系统架构:系统架构主要是关注的是⾮功能性要求的实现,如: 1.数据安全、容灾需求 2.维护需求 3.扩展需求 4.⾼可⽤需求 5.资源、成本要求 6.保证每⼀模块⾼内聚低耦合 7.容量(性能和存储)需求 8.并发访问量,⾼...
3.1 3分离关注点 3.2 面向对象设计 3.2.1 面向对象基本设计原则 3.2.2 高级原则 3.3 从原则到模式 3.3.1 模式究竟是什么 3.3.2 模式vs.惯用法 3.3.3 依赖注入 3.4 在设计时就考虑需求 ...
您将了解如何使用AOP来处理横切关注点,例如日志记录、事务管理和安全性,而不必污染核心业务逻辑。 AOP的实际应用: 我们将提供实际的示例和案例,展示如何使用AOP来改善代码的可维护性和可扩展性。您将了解如何在...
38.20 PersistentObject和关注分离 38.21 未决问题 第39章 架构的文档化:UML和N+1视图模型 39.1 SAD和架构视图 39.2 表示法:SAD的结构 39.3 示例:NextGen POS的SAD 39.4 示例:Jakarta Struts 的SAD 39.5 ...
38.20 PersistentObject和关注分离 38.21 未决问题 第39章 架构的文档化:UML和N+1视图模型 39.1 SAD和架构视图 39.2 表示法:SAD的结构 39.3 示例:NextGen POS的SAD 39.4 示例:Jakarta Struts 的SAD 39.5 ...
38.20 PersistentObject和关注分离 38.21 未决问题 第39章 架构的文档化:UML和N+1视图模型 39.1 SAD和架构视图 39.2 表示法:SAD的结构 39.3 示例:NextGen POS的SAD 39.4 示例:Jakarta Struts 的SAD 39.5 ...