衡量架构的合理性

架构为业务服务，没有最优的架构，只有最合适的架构，架构始终以高效，稳定，安全为目标来衡量其合理性。

架构设计本质就是解决软件复杂度带来的问题，软件复杂度表现形式有很多种，比如业务复杂度、性能复杂度、可用性复杂度、可扩展性复杂度、安全复杂度等；任何一个系统都有它侧重解决的复杂度问题，理解每个架构方案背后需要真正解决的是软件复杂度的什么问题，是评判一个架构设计目的性的关键因素，这也是做架构设计中常提的系统约束条件。

业务复杂度体现的是如何来拆解业务，找到合适的软件元素和组件，按合适结构进行连接；性能复杂度体现的是找到软件元素，进行合适连接形成一定结构，达到高性能要求。比如说一个大型ERP系统，属于业务复杂度高的系统，你该如何去拆分它，拆分成一个个独立完备、具有明确业务边界的组件，这是做架构设计需要思考的。再比方说做一个秒杀系统，系统复杂度要求就是性能复杂度，怎么能扛住秒杀的洪峰，这是性能复杂度需要解决的问题。

合理的架构设计：

5.1. 业务需求角度

能解决当下业务需求和问题
高效完成业务需求: 能以优雅且可复用的方式解决当下所有业务问题
前瞻性设计: 能在未来一段时间都能以第2种方式满足业务，从而不会每次当业务进行演变时，导致架构翻天覆地的变化。

5.2. 非业务需求角度

①. 稳定性。指标：

高可用：要尽可能的提高软件的可用性，我想每个操作人都不愿意看到自己的工作无法正常进行。黑盒白盒测试、单元测试、自动化测试、故障注入测试、提高测试覆盖率等方式来一步一步推进。
②. 高效指标：

文档化：不管是整体还是部分的整个生命周期内都必须做好文档化，变动的来源包括但不限于BUG，需求。
可扩展：软件的设计秉承着低耦合的理念去做，注意在合理的地方抽象。方便功能更改、新增和运用技术的迭代，并且支持在适时对架构做出重构。
高复用：为了避免重复劳动，为了降低成本，我们希望能够重用之前的代码、之前的设计。这点对于架构环境的依赖是最大的。
③. 安全指标

安全：组织的运作过程中产生的数据都是具有商业价值的，保证数据的安全也是刻不容缓的一部分。以免出现XX门之类丑闻。加密、https等为普遍手段