可用性
可用性指系统长时间无故障运行的能力。通常根据整个系统的停机时间是否超过了预期的时间的百分比来衡量系统的可用性。影响系统可用性的因素主要有系统错误、基础设施问题、恶意攻击和系统负载等。使用下面罗列的技术来最大程度的提升系统的可用性。
关键问题
l 物理层故障，如数据库或应用服务器可能出现当机或无响应，导致整个系统不可用；
l 安全漏洞可能导致拒绝服务（DoS）攻击，阻断授权用户访问系统；
l 资源使用不当会影响系统的可用性。例如，过早的获取资源并长时间占用，这样会导致资源匮乏，无法处理并发用户的请求；
l 缺陷或应用程序故障会导致整个系统不可用；
l 频繁的升级，如不断推出安全补丁和用户升级程序也会导致系统可用性降低；
l 网络故障导致系统不可用。
关键决策
l 如何设计关联到各个物理层上的故障恢复功能；
l 如何设计一个冗余站点以规避一些自然因素（如地震或台风）造成的系统不可用；
l 如何设计使系统支持在运行时升级；
l 如何设计合适的异常处理机制以减少应用系统的故障几率；
l 如何处理不可靠的网络连接。
关键技术
l 使用支持网络均衡负载（NLB）的Web服务器，防止请求被发送到发生故障服务器；
l 使用磁盘阵列以减少磁盘故障导致的系统不可用发生的几率；
l 部署位于不同地域的站点，在这些站点之间对所有有效请求做均衡处理，这是一项先进的网络技术；
l 为了尽量减少系统的安全漏洞，减小攻击面，识别恶意行为。使用应用监听来检测意外的行为，并实施全面的数据验证机制；
l 设计支持偶尔连接的客户端，如富客户端（Rich Client）。
概念完整性
概念完整性定义了整个设计的一致性与连贯性。包括组件与模块的设计方式，也包括如代码风格以及变量的命名方式等要素。统一的系统是非常易于解决问题的，因为您能够识别哪些方面与系统的整体设计一致，哪些方面有悖与系统的整体设计。相反，概念不完整的系统经常会受到界面变更，频繁的模块变动，任务执行一致性较差等问题的影响。
关键问题
l 在设计中不同的关注领域被混杂在一起；
l 没有遵循一致的开发过程。
l 不同开发组之间的合作与沟通问题会对应用系统的整个开发周期带来影响。
l 不完善的设计与编码标准。
l 已有的系统的需求限制了使用重构或二次开发的手段形成新系统的能力。
关键决策
l 如何识别关注点并且将相同的关注先组织到同一逻辑层中。
l 如何管理开发过程。
l 如何推动整个应用系统全生命周期的协作和沟通。
l 如何建立并施行设计与编码标准。
l 如何建立抛弃遗留技术的迁移路线。
l 如何将应用系统与外部依赖相隔离。
关键技术
l 在设计阶段引入公开的规范，识别出关注领域并将相同领域的关注点组织到同一逻辑层中；
l 执行应用程序生命周期管理（ALM）评估；
l 建立一个集成工具来处理相关的流程，沟通和协作的开发过程；
l 建立公共的设计和编码标准；
l 引入代码复查机制以确保开发过程遵循开发准则；
l 使用网关模式集成遗留系统；
l 提供描述整个应用系统的结构的文档。
灵活性
灵活性是系统适应不同的环境及应对业务规则变化的能力。一个灵活的系统仅仅通过简单的修改就能够应对不同的用户与系统的需求。
关键问题
l 代码过于庞大，脆弱、难于管理；
l 庞大且不断增长的代码导致重构工作异常艰难；
l 现有代码过于复杂；
l 通过多种不同的方式实现了相同的逻辑。
关键决策
l 如何处理动态业务规则，如授权、数据、流程规则出现了变更。
l 如何处理动态用户界面，如授权、数据、流程界面出现了变更。
l 如何应对数据与逻辑处理的变更。
l 如何确保组件和服务具有明确界定的职责和关系。
关键技术
l 如果只有业务规则取值趋于变化的话，则使用业务组件封装业务规则。
l 如果企业决策规则趋于变化的话，则使用第三方的程序，如业务规则引擎。
l 如果业务流程趋于变化，则使用工作流引擎。
l 明确界定系统的层级或关注领域，清晰地划分系统的UI，业务流程以及数据访问功能。
l 设计高内聚，松耦合的组件，使得系统的灵活性、可替换性、重用性最大化。
To be continued …