模块、组件划分，组件封装，多线程考虑，防火墙考虑（如只能单向通过，在架构的时候就需要考虑清楚）

需求，领域，分析，设计，实施等模型

保持架构的健壮和稳定性，让架构适应变化

严重问题：如何解耦呢？

扩展性（也包括硬件扩展），灵活性，

软件性能

可维护性

可伸缩性

高内聚，低耦合

针对主要需求的（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，当前段业务组件更新实体数据，实时更新到数据库中