2013年下半年试题二：论企业应用系统的分层架构风格
论文库链接：系统架构设计师论文
论文题目
软件架构风格是描述一类特定应用领域中系统组织方式的惯用模式，反映了领域中诸多系统所共有的结构特征和语义特征，并指导如何将各个模块和子系统有效组织成一个完整的系统。分层架构是一种常见的软件架构风格，能够有效简化设计，使得设计的系统结构清晰，便于提高复用能力和产品维护能力。
由于大量企业应用系统都由界面呈现、业务逻辑、数据存储三类功能构成，因此广泛采用分层架构风格进行系统设计。
请围绕“企业应用系统的分层架构风格”论题，依次从以下三个方面进行论述。
1.概要叙述你参与管理和开发的企业应用系统建设项目以及你在其中所承担的主要工作。
2.请结合项目实际情况，指出应用系统都有哪些层次以及每个层次的主要功能。
3.请结合项目实际情况，指出设计每个层次时需要注意的问题及相应的解决方案。
写作要点
一、简要描述所参与管理和开发的企业应用系统建设项目，并明确指出在其中承担的主要任务和开展的主要工
二、需要结合项目实际情况指出所开发的应用系统的总体架构，特别是架构的层次关系。分层架构设计是一种常见的架构设计方法，能够有效简化设计，使设计的系统结构清晰，便于提高复用能力和产品维护能力。一般来说，企业应用系统的架构可以分为 表现层、中间层和持久层三个层次。表现层。
表现层主要负责接收用户的请求，对用户的输入、输出进行检查与控制，处理客户端的一些动作，包括控制页面跳转等，并向用户呈现最终的结果信息。表现层主要采用MVC结构来实现。控制器负责接收用户的请求并决定应该调用哪个模型来处理;然后，模型根据用户请求调用中间层进行相应的业务逻辑处理，并返回数据;最后，控制器调用相应的视图来格式化模型返回的数据，并通过视图呈现给用户。
中间层
中间层主要包括业务逻辑层组件、业务逻辑层工作流，业务逻辑层实体和业务逻辑层框架四个方面，业务逻辑层组件分为接口和实现类两个部分，接口用于定义业务逻辑组件，定义业务逻辑组件必须实现的方法。通常按模块来设计业务逻辑组件，每个模块设计为一个业务逻辑组件，并且每个业务逻辑组件以多个DAO组件作为基础，从而实现对外提供系统的业务逻辑服务。业务逻辑层工作流能够实现在多个参与者之间按照某种预定义的规则传递文档、信息或任务的过程自动进行，从而实现某个预期的业务目标，或者促进此目标的实现。业务逻辑层实体提供对业务数据及相关功能的状态编程访问，业务逻辑层实体数据可以使用具有复杂架构的数据来构建，这种数据通常来自数据库中的多个相关表。业务逻辑层实体数据可以作为业务过程的部分I0参数传递，业务逻辑层的实体是可序列化的，以保持它们的当前状态。业务逻辑层是实现系统功能的核心组件，采用容器的形式，便于系统功能的开发、代码重用和管理。
持久层。
持久层主要负责数据的持久化存储，主要负麦将业务数据存储在文件、数据库等持久化存储介质中。持久层的主要功能是为业务逻辑提供透明的数据访问、持久化、加载等能力。
三、考生需要结合项目实际情况，举例说明在设计表现层、中间层和持久层时需要考虑的主要问题，例如:在持久层设计时需要考虑MVC模型中的模型、视图和控制器分别对应哪些组件;在中间层设计时需要考虑框架与业务组件之间的关系;在持久层设计时需要考虑如何支持对多种类型数据的透明访问。
论文参考
论企业应用系统的分层架构风格
摘要
2024年1月，我以架构设计师的身份参与了企业OA系统项目的改良与设计。该系统的主要功能有打卡签到、公文流转、物品申购等。根据该系统打卡签到难、公文流转烦、物品申购繁的特性，经过技术小组认真研究讨论后，一致认为应该采用分层软件架构风格。我们将OA系统分成三个层次，分别是界面呈现、业务逻辑、数据存储。这三个层次分工明确，各司其职，分别完成好自己相应层次的职责，有效简化了设计，使得系统的结构变得清晰，便于提高复用和维护能力。最终在编程小组的努力与奋斗下，该系统于2024年12月成功上线并运行至今，得到了领导和同事们的普遍认可，解决了日常办公中打卡签到难、公文流转烦、物品申购繁等问题，提高了工作效率。
正文
2024年1月，我以架构设计师的身份参与了企业OA系统项目的改良与设计。该系统的主要功能有打卡签到、公文流转、物品申购等。根据该系统打卡签到难、公文流转烦、物品申购繁的特性，编程组反映希望可以采用方便复用和维护简单的架构风格，经过技术小组认真研究讨论后，一致认为应该采用分层软件架构风格。采用分层架构风格可以有效地反映领域中诸多系统所共有的结构特征和语义特征，并指导如何将各个模块和子系统有效组织成一个完整的系统。我们将OA系统分成三个层次，分别是界面呈现、业务逻辑、数据存储。这三个层次分工明确，各司其职，分别完成好自己相应层次的职责，有效简化了设计，使得系统的结构变得清晰，便于提高复用和维护能力。最终在编程小组的努力与奋斗下，该系统于2024年12月成功上线并运行至今，得到了领导和同事们的普遍认可，解决了日常办公中打卡签到难、公文流转烦、物品申购繁等问题，提高了工作效率。
本次开发的OA系统大致分为三个层次，分别是界面呈现、业务逻辑、数据存储。界面呈现的主要功能是将系统涉及到的所有功能完整地呈现给用户，方便用户可以便捷地使用功能。当用户进入首页界面时，要将经常使用的打卡签到、加班统计、待办事项等功能映入眼帘，方便用户及时地处理相关信息。业务逻辑的主要功能是个别业务涉及到需要高效运算的时候，系统能够提供相应的计算支撑能力，提高系统的性能。如：公车派送模块，系统需要根据每辆公车的使用情况，计算出将用车的工作人员第一时间送达目的地的路线及相应备选方案，可以有效地提高工作人员的外出办事效率。数据存储的主要功能是将用户在使用软件过程中产生的数据安全地存储在数据库中，方便后期使用过程中对数据进行追踪审计，可以极大地提高排查数据错误的效率。如：加班统计模块，财务需要根据该模块统计的加班数据将加班费精准地发放给每位加班人员，如果加班数据发生遗漏或被替换将会直接影响到工作人员的切身利益，所以在每次录入数据时要对数据进行核查，确保数据正确。
在设计OA系统时需要注意很多方面的问题，如：性能、可用性、安全性、可修改性等系统质量属性。下文将结合项目实际情况从基于界面呈现、业务逻辑、数据存储的分层架构风格这三个方面详细论述在设计每个层次时需要注意的问题及相应的解决方案。
一、基于界面呈现层的分层架构风格设计。
为了解决系统需支持PC端与移动端访问，传统布局方式在不同设备与浏览器中适配成本高，影响用户体验的问题。采用响应式设计与组件化开发模式，提升界面兼容性与开发效率。引入Vue3 + Vant UI组件库，基于CSS Grid与Flex布局实现响应式界面；设计原子化组件库，统一按钮、表单等基础控件，减少重复开发；通过用户行为分析调整首页功能布局，将高频功能置于优先位置。界面呈现层主要负责用户交互与界面展示，整合前端技术（HTML5 + CSS3 + Vue.js）实现响应式布局，支持多端访问。首页集中展示高频功能（如打卡签到、待办事项等），提升用户操作效率。采用html、css、javascript等前端编程语言根据用户向前端小组反映的使用需求，再按照美工的要求对界面进行设计、润色、渲染等，将涉及到OA系统的多个功能简洁地呈现在用户面前，提高系统的可操作性。
二、基于业务逻辑层的分层架构风格设计。
为了解决部分业务模块（如加班统计、公车调度）规则复杂，计算密集，易成为系统性能瓶颈的问题。明确每个功能分别采用什么模式进行设计。如，加班费统计模块。对加班统计功能的加班费计算规则进行明确，在工作日时间不算加班、连续加班时长不满足3个小时不算加班等，所以建议采用计算规则模式对其进行设计，可以有效地提高加班费计算效率，间接地促进工作积极性、提高工作效率。采用规则引擎与异步处理机制，分离业务规则与执行逻辑，提升系统响应速度。在加班统计模块中引入Drools规则引擎，将加班条件配置化为可管理规则；对公车调度等计算密集型任务采用异步队列处理，避免阻塞主线程；通过单元测试与性能压测验证逻辑正确性与执行效率。封装核心业务流程与规则，提供统一的服务接口。例如，在公车调度模块中，系统基于实时数据计算最优路线与派车方案；在加班统计模块中，自动校验加班规则并生成统计结果。
三、基于数据存储层的分层架构风格设计。
为了解决系统上线后用户量激增，频繁的读写操作导致数据库性能下降，同时敏感数据（如薪资、考勤）面临安全风险的问题。实施读写分离与多级缓存策略，强化数据备份与校验机制。部署MySQL主从复制，将查询请求路由至从库，减轻主库压力；使用Redis集群缓存热点数据（如用户信息、菜单权限）；对财务相关数据实行双向校验与异地备份，确保数据一致性与灾难恢复能力。对数据存储量较大、数据重要程度较高的功能模块进行梳理，重点关注它们的数据体量及所需的安全性程度，尤其是涉及到金钱等敏感数据要格外小心。对数据重要程度较高的工资查询、加班统计等模块，如果数据发生遗漏或被替换将会直接影响到工作人员的切身利益，所以在每次录入数据时要利用核查工具对数据进行检验，确保数据正确。对重要敏感数据进行备份，采用异地备份的方式，将重要数据及时同步至异地的数据库服务器中，防止当地突然发生火灾等不可抗拒的情况，造成系统数据丢失财产不可挽回的现象。通过异地备份可以有效地解决该问题，提高OA系统的安全性。
最后经过编程小组的不懈努力与奋斗，终于在2024年12月顺利完成该项目的实施并成功上线运行至今，得到了领导和同事们的普遍认可，解决了日常办公中打卡签到难、公文流转烦、物品申购繁等问题，提高了工作效率。但在试运行阶段也暴露出了一些问题，如：由于OA系统运行效果良好，使用人数逐渐增多，发生了系统奔溃现象。通过技术小组排查后，确认是由于短时间内使用人数频次增多导致的服务器运行失效问题。之后马上召开紧急会议，商议确定采用负载均衡策略将资源向使用频繁的功能进行倾斜，有效地解决了该问题。同时也感谢领导给我们技术小组开发OA系统的机会，让我的系统架构设计能力得到进一步的提高，希望能够继续参与到下一次信息化项目建设中，为企业的发展添砖加瓦，贡献微薄之力。