架构设计首先依据是基于业务需求，其次架构设计是经过系统性地思考, 权衡利弊之后结合现有资源约束下的最合理决策，最终明确的系统骨架: 包括子系统, 模块, 组件. 以及他们之间协作关系, 约束规范, 指导原则. 并由它来指导团队中的每个人思想层面上的一致。
可以包括但不限于以下几方面：
1、系统性思考的合理决策：比如技术选型、解决方案等。
2、明确的系统骨架：明确系统有哪些部分组成。
3、系统协作关系：各个组成部分如何协作来实现业务请求。
4、约束规范和指导原则：保证系统有序，高效、稳定运行。
什么是风险驱动设计
对于未知的业务，可能存在诸多未知的风险，风险驱动架构设计是发现问题并解决问题，通过对业务需求分析可能存在风险点，寻找最合适解决方案。
架构设计不仅要能够满足功能需求还要能够满足非功能需求，例如性能、安全、可用性、可靠性、可扩展性等质量属性，并约束整个系统，风险驱动设计是通过风险管理过程，应对计划，助于降低决策错误之几率、避免损失之可能。
如何实施风险驱动设计
对业务需求深入了解
业务需求了解是架构设计的基础，只有对业务需求足够的了解，才能够发现出表面的风险，进而挖掘底层存着的风险。如果对需求理解不够清楚，另外业务没有应有的预判，那么就会导致架构设计可能满足不了需求特性，不能有该有的质量属性，例如：可扩展性、性能、安全等等，总之架构设计一方面明确系统的骨架，另一方通过业务需求深入了解之后发现可能存在的风险点，从而降低或消灭这些风险点。
通过风险管理过程、应对计划、降低风险
风险管理过程告诉我们如何识别风险、对风险如何描述、及对风险如何分析，如何制定风险应对计划，帮助我们消灭风险或降低风险。在系统发展的过程中可能面临的风险如下：
需求方面
需求在系统的发展过程占据主导作用，也是风险的起源，需求本身特性是善变的，不是一成不变的，那么架构设计也是需要随着需求变更而变更的，在这个变化的过程风险也是一直存在其中的。
技术选型方面
技术选型是对于项目的成功是至关重要的，技术选型需要兼顾几方面，第一是能够满足业务属性，从实际业务出发，技术圈里流行一句话:不以业务为基础的架构都是耍流氓；第二是团队成员对该技术较为擅长，能够得到团队成员的拥护。第三是看社区活跃度，建议选择活跃度高，自然知名度就高了，也能很快为大家所熟知和学习，所以，活跃度高，也可以认为其推广度也是不错的，不过，还有一种技术也会有极高的活跃度：有极大争议的技术，这种情况只能持有更为谨慎的态度了，除非到了非用不可的地步了。第四是技术前瞻性，这个不太好指标量化，只能考技术管理者的经验而定，相对比较流行的技术。
代码架构方面
代码架构在系统中是非常重要的，是根基，决定未来整体项目的代码风格和维护性，代码架构是为了提供更好的可读性和可维护性。代码架构是为了研发人员提供切实可行的指导，如果代码架构设计不足，就会造成全局的架构设计。
例如：代码规范，如果团队内部没有适合的团队规范，那么每个人的风格都不统一，最终将会导致代码无法维护，可读性差，如果再次在此基础上新增或修改代码，面临的风险就会增加很多；再例如中间件的使用，如果大家没有标准化，那么就可能会导致每个使用方式都统一，久而久之就会导致无法维护、可读性差，同样的道理，风险也会随之而来，另外没有代码架构设计，那么就没有办法做技术架构，很多技术设施就无法统一建设，从而就没有办法为团队赋能。
数据架构方面
数据架构这块是系统的最下层，往往数据架构设计大部分决定上层业务架构和应用架构设计方案，数据架构这方面涉及数据存储选型、关系型非关系型、数据模型、表结构、主从方式等，还涉及数据安全方面，上层架构基本上基于数据架构设计和实现的。例如：在交易系统中，两个人相互转账，如果A要给B转账5块钱，在这样的需求如何对数据架构进行设计？
首先：分析交易系统中对数据一致性比较高，可以采用Mysql数据库作为底层数据架构的存储。
其次：对Mysql数据库结构需要使用innodb存储引擎，原因是支持事务，其他的存储引擎不支持事务。
再次：在进行转账时，需要开启事务，在A开始转账时首先对转账金额进行检查，确保转账金额未超出账户总金额
再次：对B账户进行相关的检查
再次：开始对A进行账户减钱操作之后，对B账户进行加钱操作
最后：提交事务，期间一旦失败确保事务未提交，从而保证数据的一致性。
业务架构方面
业务架构包括业务规划，业务模块、业务流程，对整个系统的业务进行拆分，对领域模型进行设计，把现实的业务转化成抽象对象，没有最优的架构，只有最合适的架构，一切系统设计原则都要以解决业务问题为最终目标，脱离实际业务的技术情怀架构往往会给系统带入大坑，任何不基于业务做异想天开的架构都是耍流氓，所有问题的前提要搞清楚我们今天面临的业务量有多大，业务未来增长走势是什么样，其过程一定是一个循序渐进逐步的过程。 合理的架构能够提前预见业务发展1~2年为宜。这样可以付出较为合理的代价换来真正达到技术引领业务成长的效果。
应用架构方面
应用架构是基于业务架构之后进一步拆分和分明，为系统划分明确的边界、职责，通过对系统拆分、业务平衡、降低了业务的复杂度、从而提升迭代效率，同时避免技术复杂性、确保业务架构落地。明确应用间通信机制和数据格式。应用的分偏向于业务，反映业务架构，应用的合偏向于技术，影响技术架构。
架构演进方面
架构演进是系统发展的必经之路，不论是从单体到分布式还是微服务再到ServceMash等等，都是业务快速发展，能够好的为业务赋能，提升产研效率，提供稳定性，那么架构演进过程面临的风险就有很多，列如：分布式情况下数据如何确保一致性，如何确保服务可用性等等，只有能够清晰认识到这些风险，对风险管理及应对，才能在架构演进的过程如鱼得水。
质量属性方面
质量属性这部分是更多偏向可用性、可靠性等等，这些都是非功能性需求，随着系统的发展可能面临的问题都是不一样的，复杂度也是如此。面对复杂的业务、每一个点在做好都能难，这方面也是如此，在每一次技术方案评审，都需要能够这方面的意识，时刻考虑如何提升系统的健壮性。
持续对风险管理
风险不只是系统建设初期才有，而是伴随着系统一直存在的，不论在什么阶段需要持续对风险管理，及时更新和监控风险，定期对风险复盘宣贯，提升团队对风险的意识，风险是无处不在的，也是未知的。如果没有对风险持续管理，那么可能面临的问题是，你的系统可能出现故障之后，你才会意识到，也有可能是你的风险管理计划不是最新，和当前的系统或者发展不匹配，那么风险管理也是没有意义的，只有时刻对风险管理计划进行管理，确保和当前的系统是匹配的。
小结
风险驱动设计是为了告知我们，架构设计能够有这方面的意识和思想去看待问题，时刻通过上述方法论对技术方案或者架构设计进行风险管理，确保架构设计在风险管理范围内，另外也要持续对风险管理更新，确保风险管理和当前系统是匹配的，是最新的，是可用的，而非形同虚设，真正能够为架构设计保驾护航，从而提升系统的稳定性，风险是无处不在，也是未知的，只有保持敬畏，才可能战胜它。
