软件架构不是一成不变的。需要时就改变它。要想做到可以修改，架构就必须保持简单。牺牲简单性的修改要抵制。
XP原则 -- YAGNI(如果你不是马上需要，就不需要去做)
延迟设计决定，知道你必须做出这些决定为止。不要在你还不知道需求的时候就做出架构决定。不要猜测。
必须保持架构品质。只有当开发者们相信它并对它负责时，才能做到这一点。
你的系统应该有一组不错的自动化测试，它们让你在进行根本的架构变更时风险最小。这为你提供了工作空间。
对你的代码进行单元测试将带来更好的软件设计，所以设计时要考虑可测试性。
好的项目计划将带来优质的设计。分配足够的时间来创建架构杰作，它们不会立即出现。
团队的组织方式必然对它产生的代码有影响。随着时间的推移，架构也会影响到团队协作的好坏。当团队瓦解时，代码的交互就很糟糕。当团队协作时，架构就集成得很好。