1. 可维护性是设计系统时最应该关注的问题。它的2个要素：
1） 结构化设计
2） 可读性
2. 较差的设计通常源自2个互不排斥的原因：
1） 架构师经验不足
2） 不够严密甚至矛盾的需求 （解决方案：提高交流 -> 敏捷迭代 + 总结，同时需要注意敏捷迭代所带来的开发成本增加和需求增加）
3. 暗示设计开始走下坡路的征兆：
1） 坚硬，因此易碎 （对修改有较大抵触：当由于依赖，以至于修改某个软件模块影响了很多其它模块）
2） 使用要比重用简单 （顽固性：因为依赖，无法、无处重用）
3） 临时修补要比彻底解决简单 （高粘度：软件难以修改）
4. 结构化设计原则：
1） 高内聚：软件模块完成一系列极为相关的功能 （SRP）
2） 低耦合：两个模块间的依赖程度较低
5. 分类关注点有助于实现结构化设计：
1） 分离关注点的核心在于将下图拆分成各不相同且最好没有重叠的功能
2） 一次只处理一个关注点！
6. OOP设计的基本原则：
1） 找到合适的对象（常用做法是：标记各个用例中所有名次和动词，名次作为类，动词作为方法）
2） 尽量降低耦合（将接口和实现分离，基于接口而不是实现编程。在.net中，若接口不足以提供你需要的哦功能，可考虑用基类）
3） 尽量保证代码重用（尽量使用对象组合黑盒重用，而不是类型继承白盒重用）
7. 组合和聚合的：
相同点：均表示has-a关系
区别：组合中容器类销毁，内部类也销毁；聚合则弱化一些，即容器类销毁，关联类仍然可以使用
8. OOP设计高级原则：
1） 开放/封闭原则（最好方式是提供一个固定接口，然后让所有可能发生变化的类实现该接口）
2） 里氏替换原则（虚方法不应该访问私有成员，而应该访问受保护成员）
3） 依赖倒置原则（控制高层次组件不应该依赖于低层次组件，二者均应依赖于接口）
9. 模式并不能为解决方案增添价值，其价值在于为架构师或开发组提供解决方案。从高处着眼，业界普遍认同的是两种模式：设计模式和架构模式。
1） 在设计、编写代码时会使用设计模式，在概括地规划系统的整体设计时会使用架构模式；
2） 另外还有一种模式：重构模式，在重构过程中使用
3） 常见架构模式：针对应用程序建模的分层和SOA、MVC、针对业务逻辑层的领域模型（Domain Model）和服务层（Service Layer）、网络相关的点对点（Peer to Peer）
4） 反模式：
http://zh.wikipedia.org/wiki/%E5%8F%8D%E6%A8%A1%E5%BC%8F 、http://en.wikipedia.org/wiki/Anti-pattern
10. IOC主流框架：Castle Windsor、Ninject、Spring.Net、StructureMap、Unity
Mock主流框架：NMock2、TypeMock、Rhino Mocks
代码分析工具：Fxcop
11. 在任何软件架构中，应将可测试性和安全性作为非功能需求考虑，并在设计早期就开始计划。
1） 可测试性：
软件通讯契约：在设计类型时，应保证总能对每个类型中每个方法回答下述3个问题：
a. 什么情况下会被调用？（先决条件，输入判断）
b. 方法结束后，将进行哪些验证？（后置条件，输出、对象状态变化）
c. 执行前后，哪些条件不会发生变化（不变量）
2） 安全性：
安全的设计始于架构，而不是以后可以补充的东西
安全开发生命周期：SDL（Secure by Design、Secure by Default、Secure in Deployment、plus in Communication）
SDL基石：分层、组件化（CAS，Code Access Security）、角色认证模型。前提条件：架构师了解需要保护的重要数据，理解相同相关威胁及系统具有哪些潜在风险。
威胁模型：STRIDE，http://msdn.microsoft.com/en-us/library/ee823878(v=cs.20).aspx
恐惧模型用于判断威胁风险：DREAD，http://msdn.microsoft.com/en-us/library/aa302419.aspx
作为架构师，应在3个层面进行监督：开发、code review、测试
12. 性能优化时机：
仅当遇到性能问题，且优化前了解相同哪里做的不好
13. AOP：
1） 主要目的是将横切关注点与核心关注点实现拆分开
2） 横切关注点：指那些将会影响到相同中多个组件的关注点。如：日志、安全、异常处理
3） 方面：就是一个可重用的组件，其中封装了项目中多个类型需要使用的同一个行为
4） 实践：Enterprise Library中PIAB