原则，作为大的方向，影响到构架的设计和实现
- 运行效率和开发效率优先级，
- 可读性和开发效率
- 安全性
- 稳定性
- 负载量
- 团队开发
- 沟通原则
确定原则就是确定一个总体的方向，当一些可选项发生冲突的时候，就可以根据总的原则进行决断。
如，当前这个系统需要进行一些技术性尝试，而不是一个生产系统，那么，我们可以不考虑过多的安全，易用，稳定方面的设计，直接实现功能，解决技术问题就可以。
再如，系统的稳定性比较重要，那么，我们的稳定性设计就一定要可靠又可靠。
再如，系统的安全性比较重要，那么，数据的安全，访问的安全就要谨慎又谨慎。
再如，系统代码的可读性和可维护性作为首位重要的原则时，代码的质量，以及规范就非常重要，当遇到代码结构不清晰，但是效率非常高的部分，团队成员就可以根据当前系统的原则进行取舍。
如果一个项目的原则有很多，我们一定要进行优先级的排列，否则，原则作为指导方向的意义就削弱了。
有了可以度量的原则，其实仍然需要团队成员的参与，才能将原则具体实施，所以，沟通和决策中的原则也应该是构架要考虑到的，虽然这离软件构架稍远了点儿。
项目中的沟通是频繁沟通，还是适当沟通，还是避免沟通。沟通的成本，时间频度、长度，形式，效果，都是需要考虑的问题
沟通的原则一般可以包括，关键活动和非关键活动的沟通。
设计沟通。
问题反馈沟通
决议原则
改进原则
策略。
- 对于总体原则的把握
- 应对变化策略
一次性的变化，如界面的文字的修改，布局设计的变更。这些属于设计的进步，不需要反复修改，那么直接修改代码即可。
比如说，有些变化是经常性的，那么
一次性的变化和经常性的的变化不是互斥的，在一定的条件和需求下，可能会相互渗透，如一次性变化变为经常性的变化，而经常性的变化转回一次性变化，但是后者往往不需要再增加工作量。
经常性的变化，或者不确定性，是构架需要解决的问题，其策略要在构架时确定。如，使用变量值作为变化依据，配置文件中的项作为变化依据，数据库中的配置表作为变化依据，还是使用外部服务作为变化依据。如元数据服务和工作流服务，都是更高级的适应变化的服务。
- 可伸缩性场景和策略
规范。
- 过程规范
- 代码规范
- 界面规范
比如，在策略中我们确定通过配置方式进行变化的隔离