模块、组件划分，组件封装，多线程考虑，防火墙考虑（如只能单向通过，在架构的时候就需要考虑清楚）
需求，领域，分析，设计，实施等模型
保持架构的健壮和稳定性，让架构适应变化
严重问题：如何解耦呢？
扩展性（也包括硬件扩展），灵活性，
软件性能
可维护性
可伸缩性
高内聚，低耦合
针对主要需求的（20%）花掉80%的时间
设计目标（11个）
必须识别那些容易变更的需求
JS框架：
JQuery
EXT（重量级）
RIA架构：
FLEX
Silverlight
分布式应用
Load balance
宏观架构，平台，软件，系统，软件等的架构
微观架构，框架架构，流程架构等
解耦：持久数据层，消息机制框架
架构方式：
自顶向下（熟练架构师）
自底向上（开发人员代码会跟着重构）
收费的 ANTS分析插件
架构注意一个Context类，负责应用程序的构建和管理
注意编译状态和运行时状态区别，架构时候特别注意
实体数据对象，数据原生对象， 领域对象经过拆分，组合，转换处理的
命名空间将系统的和不同dll的命名空间用空行分开
命名空间的分隔：公司/项目/模块/工程/命名空间
研究一下数据缓存机制，内存数据的持久化和内存数据的并发操作，
1， 内存数据被修改，但持久失败
2， 内存数据同时被两个或多个现成修改
3， 脏数据问题：甲线程修改了一条记录，乙线程取了被修改的数据返回给客户，甲线程持久操作，但失败，那乙读脏数据了。
抽象不应该依赖细节，细节要依赖抽象
针对接口/抽象编程
如果一些类不叫稳定，或者以后基本不变，也不会衍生多个不同实现的子类，则不要设计成抽象结构，这样显得画蛇添足了。
10万条订单存储在内存（缓存服务器）是个什么概念？
缓存服务器中命中率算法，淘汰掉什么样的数据？
那其他各种单据难道都要存于缓存？硬件开销，是否是良好的架构，该架构实用于什么样的一个平台应用环境？
WinForm UI控件在添加删除数据库时候，可在之前和之后分别执行BeginUpdate()和EndUpdate()
大型系统的session架构设计
云计算框架架构设计
ServerFarm 集合
RTI RT Control(实时控制中心)动态部署服务到ServerFarm中
事务补偿
业务原生特点，领域模型
GRASP模式
O/RMapping 设计思路
按照业务原生整合表，业务实体代表业务实际数据对象
业务实体间维护关系，关系1对多，避免多对多关系
对于事务处理，交由数据库来处理
发起事务：组装成数据库事务抛给数据库处理，在数据库处理返回后再处理DOL层中的实体对象
对于静态数据（查询数据），采用缓存机制进行持久化对象缓存
对于动态数据（尤其是频率比较高），采用延时加载机制
双向ORMapping，写一套数据更新的SQL，当前段业务组件更新实体数据，实时更新到数据库中