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