系统架构设计师——层次式架构设计理论与实践

最新推荐文章于 2024-09-12 11:29:14 发布

吴代庄

最新推荐文章于 2024-09-12 11:29:14 发布

阅读量897

点赞数 26

分类专栏： # 系统架构设计师文章标签：系统架构系统架构设计师

本文链接：https://blog.csdn.net/Luck_gun/article/details/141791443

版权

系统架构设计师专栏收录该内容

29 篇文章 11 订阅

订阅专栏

层次式体系结构概述

层次式体系结构是一种将系统组织成多个层次的设计方法，每个层次为上层提供服务，并作为下层的客户。这种结构有助于实现关注点分离，使得每个组件只负责本层的逻辑，从而提高了系统的可维护性和可扩展性。

在层次式体系结构中，每一层最多只影响两层，只要给相邻层提供相同的接口，就可以允许每层用不同的方法实现。这种设计为软件重用提供了强大的支持。同时，由于组件的划分很容易明确组件的角色和职责，因此也比较容易开发、测试、管理和维护。

然而，在设计层次式体系结构时，需要注意以下两点：

污水池反模式（architecture sinkhole anti-pattern）：请求流简单地穿过几个层，每层里面基本没有做任何业务逻辑，或者做了很少的业务逻辑。这种情况可能导致系统的性能和可维护性下降。
分层架构可能会让应用变得庞大：即使表现层和中间层可以独立发布，但分层架构可能会导致分布模式复杂、健壮性下降、可靠性和性能不足以及代码规模膨胀等问题。

总之，层次式体系结构是一个可靠的通用架构，适用于许多应用场景。但在设计时，需要注意避免污水池反模式和应用变得过于庞大的问题。

表现层框架设计

表现层框架设计是指在软件开发中构建与用户直接交互的界面部分的过程，以确保提供直观、响应式和高效的用户体验。在多层架构的应用程序中，表现层是用户与系统之间交互的接口。下面将具体探讨如何在软件开发中实现一个高效且用户友好的表现层框架：

选择适当的设计模式
- MVC模式：MVC（Model-View-Controller）模式是最常用来设计表现层的一种模式，它通过分离模型、视图和控制器三个组件来管理用户界面和后端逻辑的复杂性。这种模式的优势在于，各组件之间的低耦合性使得开发可以更加模块化，便于日后的维护和扩展。
- MVP模式：MVP（Model-View-Presenter）模式是将MVC中的控制器角色替换为一个称为“Presenter”的组件，从而进一步解耦视图和模型的关系。这样的设计让视图变得非常简单，只保留基本的渲染功能，而所有的逻辑都放在Presenter中处理。
- MVVM模式：MVVM（Model-View-ViewModel）模式通过引入ViewModel来连接视图和模型，实现了双向数据绑定。这种方式简化了界面与数据之间的同步问题，常用于现代前端框架如WPF和React。
确保优秀的用户体验
- 响应式设计：在多种设备和屏幕尺寸上提供一致的用户体验是现代网站设计的基本要求。利用响应式设计方法，可以创建在不同设备上都表现良好的界面。
- 交互设计：合理规划用户与系统的交互流程，减少用户的操作步骤，增加直观的反馈，提高整体的用户满意度。例如，通过表单的即时验证给予用户明确的错误信息，可以避免不必要的提交延误。
使用合适的技术栈
- 前端技术：HTML5和CSS3提供了基础的页面结构和样式设计能力，JavaScript及其框架（如React, Angular, Vue.js）则大大提升了前端开发的互动性和效率。
- 后端技术：像Spring MVC、Struts这样的后端框架帮助开发者快速搭建强大的服务器端应用，同时提供RESTful API方便前后端的交互。
优化数据交互和处理
- 高效的数据绑定：在表现层中实施数据绑定技术，可以实现模型与视图之间的自动同步，减少手动DOM操作的复杂性和容易出错的问题。
- 前后端分离：采用前后端分离的策略，通过API与后端通信，不仅可以分散服务器的压力，还能更好地应对多种客户端的接入需求。
进行性能优化和测试
- 性能优化：采取技术手段如代码分割、延迟加载、使用CDN等策略优化页面加载速度和运行效率。
- 全面的测试：包括单元测试、集成测试和端到端测试在内的多层次测试策略保证表现层的代码质量和功能正确性。

中间层架构设计

中间层架构设计是软件架构中的一个重要组成部分，它主要负责处理业务逻辑。在中间层架构设计中，业务逻辑组件通常分为接口和实现类两个部分。

接口用于定义业务逻辑组件必须实现的方法，是整个系统运行的核心。通常按模块来设计业务逻辑组件，每个模块设计一个业务逻辑组件，并且每个业务逻辑组件以多个DAO（Data Access Object）组件作为基础，从而实现对外提供系统的业务逻辑服务。增加业务逻辑组件的接口，是为了提供更好的解耦，控制器无须与具体的业务逻辑组件耦合，而是面向接口编程。

实现类是业务逻辑组件的具体实现，它以DAO组件为基础，必须接收Spring容器注入的DAO组件，因此必须为业务逻辑组件的实现类提供对应的Setter方法。业务逻辑组件的实现类将DAO组件接口实例作为属性（面向接口编程），而对于复杂的业务逻辑，可能需要访问多个对象的数据，那么只需在这个方法里调用多个DAO接口，将具体实现委派给DAO完成。

工作流管理联盟（Workflow Management Coalition）将工作流定义为：业务流程的全部或部分自动化，在此过程中，文档、信息或任务按照一定的过程规则流转，实现组织成员间的协调工作以达到业务的整体目标。用工作流的思想组织业务逻辑，优点是：将应用逻辑与过程逻辑分离，在不修改具体功能的情况下，通过修改过程模型改变系统功能，完成对生产经营部分过程或全过程的集成管理可有效地把人、信息和应用工具合理地组织在一起，发挥系统的最大效能。

业务逻辑层实体具有以下特点：

业务逻辑层实体提供对业务数据及相关功能（在某些设计中）的状态编程访问。
业务逻辑层实体可以使用具有复杂架构的数据来构建，这种数据通常来自数据库中的多个相关表。
业务逻辑层实体数据可以作为业务过程的部分I/O参数传递。
业务逻辑层实体可以是可序列化的，以保持它们的当前状态。
业务逻辑层实体不直接访问数据库，全部数据库访问都是由相关联的数据访问逻辑组件提供的。
业务逻辑层实体不启动任何类型的事务处理，事务处理由使用业务逻辑层实体的应用程序或业务过程来启动。

在应用程序中表示业务逻辑层实体的方法有很多（从以数据为中心的模型到更加面向对象的表示法），如XML、通用DataSet、有类型的DataSet等。

业务框架位于系统架构的中间层，是实现系统功能的核心组件。采用容器的形式，便于系统功能的开发、代码重用和管理。大大降低业务逻辑和相邻各层的耦合。表示层代码只需要将业务参数传递给业务容器，而不需要业务层多余的干预。有效地防止业务层代码渗透到表示层。

Domain Model是领域层业务对象，它仅仅包含业务相关的属性。Service是业务过程实现的组成部分，是应用程序的不同功能单元，通过在这些服务之间定义良好的接口和契约联系起来。接口是采用中立的方式进行定义的，这使得构建在各种这样的系统中的服务可以以一种统一和通用的方式进行交互。这种具有中立的接口定义（没有强制绑定到特定的实现上）的特征称为服务之间的松耦合。松耦合系统的好处有两点：一是它的灵活性；二是当组成整个应用程序的每个服务的内部结构和实现逐渐发生改变时，它能够继续存在。Controller服务控制器是服务之间的纽带，不同服务之间的切换就是通过它来实现的。通过服务控制器控制服务切换可以将服务的实现和服务的转向控制分离，提高了服务实现的灵活性和重用性。

数据访问层设计

数据访问层（Data Access Layer，DAL）是软件架构中负责与数据源进行交互的部分。它的主要职责是将数据持久化存储到数据库中，以及从数据库中检索数据。为了实现这些功能，数据访问层采用了多种访问模式。以下是五种常见的数据访问模式：

在线访问：这是最基本的数据访问模式，也是在实际开发过程中最常采用的。在这种模式下，数据访问会占用一个数据库连接，通过这个连接不断地与后台的数据源进行交互。
Data Access Object（DAO）：DAO模式是标准J2EE设计模式之一，开发人员常常用这种模式将底层数据访问操作与高层业务逻辑分离开。一个典型的DAO实现通常包括一个DAO工厂类、一个DAO接口、一个实现了DAO接口的具体类以及数据传输对象（DTO）。具体的DAO类包含访问特定数据源的数据的逻辑。
Data Transfer Object（DTO）：DTO是经典EJB设计模式之一。DTO本身是这样一组对象或是数据的容器，它需要跨不同的进程或网络的边界来传输数据。这类对象本身应该不包含具体的业务逻辑，并且通常这些对象内部只能进行一些诸如内部一致性检查和基本验证之类的方法，而且这些方法最好不要再调用其他的对象行为。在具体设计这类对象时，通常可以有如下两种选择：使用编程语言内置的集合对象，或者通过创建自定义类来实现DTO对象。
离线数据模式：离线数据模式是以数据为中心，数据从数据源获取之后，将按照某种预定义的结构存放在系统中应用的中心。离线，对数据的各种操作独立于各种与后台数据源之间的连接或是事务。与XML集成，数据可以方便地与XML格式的文档之间互相转换。独立于数据源，离线数据模式的不同实现定义了数据的各异的存放结构和规则，这些都是独立于具体的某种数据源的。
对象/关系映射（Object/Relation Mapping，O/R Mapping）：对象/关系映射的基本思想来源于这样一种现实：大多数应用中的数据都是依据关系模型存储在关系型数据库中；而很多应用程序中的数据在开发或是运行时则是以对象的形式组织起来的。那么，对象/关系映射就提供了这样一种工具或平台，能够帮助将应用程序中的数据转换成关系型数据库中的记录；或是将关系数据库中的记录转换成应用程序中代码便于操作的对象。