设计前的考虑和准备工作

　　1 对业务需求的理解重要性远远胜于对技术架构的理解

　　2 架构包含技术架构和业务架构

　　3 没有万能和通用的架构，只有符合自身业务需求的架构

　　4 架构本身的复杂性要截至在架构设计阶段

　　5 扩展性和健壮性是架构设计要考虑的重要内容．

　　6 第三方工具，开源组件，EnterpriseLib都可借鉴，但绝对不是照单全收

　　架构设计前需求准备的相关知识

　　1 对业务系统中业务的宏观和整体理解．

　　2 对DotNet分布式技术的相关知识储备

　　3 对Rational统一过程4+1视图的理解

　　4 对架构，组件，充用，设计模式，第三方工具组件的学习和借鉴．

　　业务层面对架构的影响

　　1 能否画出全局的用例视图,用例驱动体现在哪里？到哪个粒度

　　2 逻辑视图是面向对象设计之本

　　3 逻辑视图在架构阶段要做到哪个层次系统／子系统／模块／单元

　　4 什么在决定部署视图？

　　5 实施视图和逻辑视图的关系，实施视图作用

　　技术层面对架构的影响

　　1 技术层面重点体现在了实施视图和部署视图里面．

　　2 技术层面重点关注的是非功能性需求．

　　3 异常／日志／安全／性能／队列／缓存／离线／

　　4 系统管理／工作流／公用类／公用组件

　　5 技术架构的缺陷泄漏对应用系统是致命打击．

　　分布式应用如何构建

　　1 现有的分布式技术Remoting // Web Service

　　2 如何选择分布式技术：业务需求，性能，开发难易工作量

　　3 智能客户端与分布式应用的关系

　　4 出现前台展示既有WinUI又有WebUI的时候的统一考虑

　　5 选择Remoting+IIS Hosting与Web Service的优缺点对比

　　6 要尽早出原型对架构进行验证．

       API设计原则

       1 所有API应该是声明式的。

        2 API对象是彼此互补而且可组合的。

        3 高层API以操作意图为基础设计。

        4 低层API根据高层API的控制需要设计

        5 尽量避免简单封装，不要有在外部API无法显式知道的内部隐藏的机制。

        6 API操作复杂度与对象规模成正比。

        7 API对象状态不能依赖于网络连接状态。

        8 尽量避免让操作机制依赖于全局状态，因为在分布式系统中要保证全局状态的同步是非常困难的。

        控制机制设计原则

       1 控制逻辑应该只依赖于当前状态。

       2 假设任何错误的可能，并做容错处理。

       3 尽量避免复杂状态机，控制逻辑不要依赖无法监控的内部状态。

       4 假设任何操作都可能被任何操作对象拒绝，甚至被错误解析。

       5 每个模块都可以在出错后自动恢复。

       6 每个模块都可以在必要时优雅地降级服务。

　　对于系统的异常和日志需求

　　1 首先理解清楚业务或系统本身对异常和日志的需求

　　2 异常和日志一定要配合使用，一些不适合抛给用户的异常要通过后台日志记录下来

　　3 业务对日志有需求，如登录日志，操作日志

　　4 完善的异常日志功能方便后期系统的维护，出现问题后的跟踪和分析

　　5 微软的AppBlock和Log4Net都可以借鉴，但要分析利弊。

　　对于系统的安全性的需求和考虑

　　1 Remoting的安全性问题，远程暴露的服务接口是否安全

　　2 系统的登录和验证机制

　　3 数据传输的安全性问题

　　4 存储在数据库中的业务数据的安全性

　　5 部署到客户端的程序集的安全性

　　对于系统缓存的考虑

　　1 要好了系统性能大幅度提升，用不好比不用还糟糕

　　2 对于客户端缓存和服务器端缓存的选择问题

　　3 对于缓存引起的同步和并发问题的考虑和解决

　　4 扩展性和健壮性是设计时要考虑的重要内容

　　业务实体的选择问题

　　1 没有使用O/R Mapping的时候千万别搞自定义类做实体

　　2 DataSet (虽对性能有影响，但开发简洁性和效率提升)

　　3 类型化和非类型化的优缺点一定要搞的很清楚．

　　4 再次强调－业务实体和数据库表间无一一对应关系．

　　5 与OO的一些区别：对象和对象操作分离开了？利弊在哪里？