应用级架构层面，作为一个应用级的架构必须对整个系统的共性应用处理进行抽象，让有共性、有规律的东西由架构来统一处理，但架构的设计并不仅限于此，还应从架构设计的原则和涉及商业领域出发主动为应用系统提供更高的价值。本系统的应用级架构基于上述思想从

安全性、

可维护性、

可用性、

可扩展性

几方面出发进行设计、实现。

    安全性，包括数据的安全性及系统本身使用的安全性，数据库的安全性虽然是安全的重要组成，但其与本文主题关系不大，此处不做重要描述。

某系统的安全策略是分为：用户名及密码的安全、系统本身的访问权限的管理。系统的访问权限，某系统在架构设计阶段充分了解分析了业界使用较多得安全策略管理机制，最终采用了‘角色’的概念（RBAC基于角色的访问控制【Role-Based Access Control】），通过实现角色的概念，

结合实际情况将安全策略分为三种权限：

登录权，

查看权，

处理权。

对同一角色赋予同样的权限，方便了使用中权限管理的设置工作量，也增加了系统安全性，实现了让合适的人看合适的信息，合适的人处理合适的业务。

    可维护性，系统的维护性主要从两方面考虑，一种是由于系统开发本身存在的缺陷，在开发阶段没有发现出来；另一种情况是在系统使用中，由于外界的变化或本身管理要求、业务流程、操作要求的变化也会引发维护工作。

    如何使投入使用的系统维护工作更方便是系统架构设计重要的考虑内容。本系统架构在设计时体现了下面的设计思路：

    尽量将通用的处理抽象到高层次，通过高层次的逻辑实现提供应用级的统一处理（这些处理主要包括对单据的主要操作，如：新增、修改、删除、保存、发送审批、单据生效、作废等）。通过这样的设计实现了下面的效果，对于一种较简单的单据，在数据库表设计好的基础上，仅通过系统配置给它相应的操作功能，此单据就可在系统中运行，不需要其他的任何代码开发。

    尽量将一个复杂的业务逻辑分为小粒度的逻辑单元，实现业务逻辑的插件结合形式。此做法一是可以将逻辑细分，当业务逻辑发生变化时可容易的将新的逻辑安装上去而不影响其他逻辑；另一个是当其中一个小逻辑需要屏蔽掉或暂时屏蔽掉时，仅需要将其从系统配置中注销掉相应的类就可实现；还有一个好处是将—一些通用的工具可方便的在整个系统中共享，例如：在日常的业务使用中许多单据需要按照固定的规则产生单据的编号、日期# 流水号，在本系统中有一个工具类，其作用就是实现此功能。当某个单据需要产生单据号时在系统的配置表中将这个类配置上去，就可实现，当不在需要时只需在配置表中去掉配置文件就可去除此功能。

   系统的架构不仅在维护工作开展上提供了方便的功能，也在问题、错误判断上采取了一些措施，以便于问题发生时可快速的定位，方便的判断、分析产生问题的原因。在这方面本系统架构主要采取了两方面措施：提供了统一的异常处理、记录详细的操作日志。

异常处理包括：业务异常（业务异常主要是体现系统的使用性，此处不具体说明）和系统异常，系统异常主要是为了维护提供方便，记录系统产生的异常状况，主要是服务器异常，并记录在服务器端，以便分析问题产生的原因。详细的操作日志：架构提供了一个整体的监控功能，记录下系统中各种操作，例如：什么单据在什么时间由谁做了什么操作。这些内容与系统异常记录进行结合分析，可快速地判断问题产生的原因，如果是业务流程中实现的问题也可快速定位到业务问题。

   可用性，对于可用性的考虑首先要从界面风格的统一，操作风格的统一，操作功能的统一入手。一个好的系统在其架构设计阶段就应该考虑操作以及界面在本系统内部的统一，使用系统的用户都不希望每一个不同的业务单据都具有一种特殊的操作风格，都希望只要学会操作一种单据，就可以在本系统内方便地操作所有的类似单据。这也是微软开发的$%&’()* 为何能够如此风靡的原因之一。

    本架构以任务的方式串接业务流程。在架构设计考虑到在系统中提供业务流程的设置功能即工作流（使用jbpm），通过设置可清楚的知道，一项工作开始后它的后续环节有那些。当一个环节结束后系统通过流程设置判断出下一个环节是什么工作，需要由谁来完成。这主要是为了提高业务由多个用户处理时的效率。用户进入系统后，不需要等待其他人员的通知和提醒，系统会提供给你当前你有什么工作任务需要开展，任务完成的时间限制是什么。系统从架构层提供了较好的、统一的系统提示功能，当业务人员在处理业务时违反了一些业务规则，系统通过统一的异常处理机制将预先设置的提示信息提供给使用者。方便的数据共享功能，

系统的流程设置功能一方面是串接业务流程，实现任务提醒功能，另一方面也提供了方便的数据共享功能。例如：当卷烟分析单制作完成后，其后续单据如销售发票、出货报告（提货单）、投保单等，其实数据与分析单中没有太大的区别，在系统中不可能让客户在后续单据中将相同的内容重新录入一遍。架构在设计时使用下面的方法保证其共享性，除了设置任务流程外还提供一个数据对应维护的记录表，记录了前后环节数据的对应关系。当用户通过系统得知某项任务需要开始时，用户开始操作后，系统通过设置的前后环节对应关系自动将前一环节的数据信息带到当前工作界面上，几乎彻底避免了当前环节的重复录入工作量。并且此数据对应维护表中的内容是可以通过架构中提供的工具进行维护的，当对应关系需要增加、修改时只要对其进行适当的维护，不需要任何代码就可实现新的对应关系。

    可扩展性，可扩展性在架构设计时主要从两方面考虑的，

一个是系统使用人员数量、次数增加以及数据容量扩大的扩展能力；

一个是当前业务流程的扩展性以及未来业务发展的扩展性。

如系统的主要用户人员及数据量基本比较固定，其数据容量的扩展也很有限，所以针对扩展性更多的是对业务扩展的考虑和设计。系统在考虑通用功能抽象时，不仅仅是由架构设计师独立完成的，其中也包含了很多有经验的需求分析师的心血，技术人员与需求人员经过多次沟通，从业务角度对流程进行环节拆分，将线性的业务流程分解为一个一个的功能处理，并结合业务流程需要，最终确定了架构支持的通用处理功能。这些通用功能经过组合后可满足绝大多数业务单据类的流程要求，对于特殊的要求也从架构中设计了一定的接口规则，可以支撑其他形式的扩展。

    系统架构提供的其他功能，数据初步验证功能：在进行信息系统开发时不可避免的要考虑数据录入时的校验功能，即判断用户录入的数据是否与数据库设置类型匹配、是否与数据库设置的长度要求符合等内容。本架构在设计时采用统一地实现数据验证功能，不需要每个开发人员单独的实现数据验证功能。

    审批功能：在进行管理信息系统的开发中不可避免地要考虑管理中的审批程序在系统中的实现，审批功能是管理信息系统建设的一个重要组成部分，其功能也是我公司信息监管管理模式的重要组成部分。本系统的架构在设计时考虑到审批的通用性，但由于审批是功能的集合，不仅仅是单一的通用功能，所以本系统架构中将审批作为一个架构的工具实现，使其与系统架构有机的结合在一起，成为本系统架构的一个重要组成部分。