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

1.关于架构过程：

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

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

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

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

2.关于遵循的原则

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

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

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

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

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

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

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

我想说，大家开发项目一定会混乱。因为大多数的开发都是经验谈，很少有方法论。混乱的根源在于需求不明确，因为很少有人将需求分层次，一般对开发级重视度不够。也很少有人对模块间的关系进行分析。所以，对模块间的关系也很少重视。但是，协作决定接口，没有协作，接口将来也不能满足应该用。开发经验很重要，但是也要有方法的指导。

架构是业务到系统的桥梁。将业务转换为我们要开发的系统。

1.需求阶段。这个阶段主目标是定关键功能，质量，约束。为概念架构做准备。

2.概念架构。这个阶段主要目标是回答客户的关心的业务（也可说是价值）如何实现，关心的问题如何解决。这里要注意：

1）用例图不能彻底覆盖系统，因为用例图并不能反应系统的非功能需求和约束。

2）不要过早概念架构不要进行接口+模块的设计。因为概念架构之前，并不能覆盖系统关键质量约束和非功能需求，也就不能明确模块间的关系，所以这阶段进行模块+接口的设计一定是不合理的。

3）概念架构只关心系统的关键部分。这样粗的看待系统，才能覆盖系统

4）围绕关进需求，质量，约束进行设计。

5）明确影响系统几个最大因素。针对关键问题进行设计。

6）概念架构要抓住客户关心的价值和担心的问题。

7）概念架构贵在有针对性，概念架构对关键部分，给出高层次的解决方案。主在确立架构大方向，针对关键要素进行设计和确定交互机制。（大体分层）

8）概念架构确定高层分割方案和其他关键决策是否合理。

概念架构的核心是发现职责，然后确定高层分割，考虑非功能需求。首先根据关键需求（质量，功能，约束，风险）发现职责（重点是发现职责，因为这是以后高层分割的基础），划分职责后确定高层分割。最后考虑非功能需求。这样大体确定系统的结构和交互机制。由于都是围绕关键功能和主要问题进行设计，所以一般情况下可以回答可会关心的功能和担心的问题如何解决。

3.细化架构。概念架构并不足以对并行开发做出指导和开发的规范。所以，要进行细化架构设计。这个时候要考虑接口+模块的设计。

累了，不写了，细化架构和之后的一些内容留到以后在写吧。今天的比较细，本人是粗人，并不喜欢太细的东西。最后写的内容一定要用一段话总结出来。就到这，剩下的以后写。

http://www.cnblogs.com/panbolin/archive/2012/11/14/2770768.html