关于架构的小整理，仅限于个人

1.关于架构过程：

a.充分分析需求，确定架构驱动力。在此阶段，要根据需求找出关键功能，关键质量，关键质量间的影响，系统约束（功能和非功能，例如团队，系统背景，性能，技术方向）

b.根据关键功能进行初步设计，然后根据初步设计进行高层分割，最后针对非功能需求（如业务需求，行业背景和约束）做出决策。在此阶段，根据以上观点，做出概念模型。

c.最后对系统整体结构进行细化。

其实架构很多时候最难得是在性能和可扩展性之间寻求平衡点，架构要多视角分析。

2.关于遵循的原则

a.依赖高层抽象，不要依赖底层的实现。

b.没必要直接通信的类，让他们通过中间类通信。就是建立一个类，a和b类都和c类通信，来访问对方。

c.子类必须可以替换任何父类出现的地方，其实就是里氏代换

d.基于查询和命令的实现。如果一个方法a,访问a会得到一个结果，那么方法a就是一个查询方法。如果方法b，更改了某些类的状态，则b就是一个命令方法。尽量将a和b的实现分离，既如果a是一个查询方法，就不应该改变其它类的状态。

e.分包的时候，将可能相互影响的类放到一个包里，不要让影响扩展到其它的包中。

f.接口职责单一，一个接口最好只负责一件事。如果让一个接口负责太多的事情，要增加功能的时候太难了，因为子类必须实现接口所有的行为。所以提倡，先组合,在抽象。先确定一个需求根据什么组成，分出职责，然后抽象，形成接口，既标准和约束，然后就开整。

以上201211142310整理，不全面，睡觉了，以后想到了，继续补充。