1.关于架构过程:
a.充分分析需求,确定架构驱动力。在此阶段,要根据需求找出关键功能,关键质量,关键质量间的影响,系统约束(功能和非功能,例如团队,系统背景,性能,技术方向)
b.根据关键功能进行初步设计,然后根据初步设计进行高层分割,最后针对非功能需求(如业务需求,行业背景和约束)做出决策。在此阶段,根据以上观点,做出概念模型。
c.最后对系统整体结构进行细化。
其实架构很多时候最难得是在性能和可扩展性之间寻求平衡点,架构要多视角分析。
2.关于遵循的原则
a.依赖高层抽象,不要依赖底层的实现。
b.没必要直接通信的类,让他们通过中间类通信。就是建立一个类,a和b类都和c类通信,来访问对方。
c.子类必须可以替换任何父类出现的地方,其实就是里氏代换
d.基于查询和命令的实现。如果一个方法a,访问a会得到一个结果,那么方法a就是一个查询方法。如果方法b,更改了某些类的状态,则b就是一个命令方法。尽量将a和b的实现分离,既如果a是一个查询方法,就不应该改变其它类的状态。
e.分包的时候,将可能相互影响的类放到一个包里,不要让影响扩展到其它的包中。
f.接口职责单一,一个接口最好只负责一件事。如果让一个接口负责太多的事情,要增加功能的时候太难了,因为子类必须实现接口所有的行为。所以提倡,先组合,在抽象。先确定一个需求根据什么组成,分出职责,然后抽象,形成接口,既标准和约束,然后就开整。
以上201211142310整理,不全面,睡觉了,以后想到了,继续补充。