系统架构设计的产生原因是因为所有的系统开发方法都要解决从需求到实践的转换问题，也就是为了提高系统质量，前提出了需求工程和各种建模技术，但是在需求和设计之间还是很难逾越，通俗来说是缺乏能够反映做决策的中间过程
一个典型的架构设计模型沿用了RUP中迭代增量的思想，由分析，描述，选择，构造和组合5个阶段组成。普通的过程模型无非是按照需求规格说明书分析出功能需求和架构需求，通过用例和场景的描述，把需求分为关键的，次要的和可选的3类，关键需求决定架构，结合软件架构风格和通用知识选择最关键，影响最大的子系统分析设计并产生构件，组合就是定义构件接口，构件作为一个封闭的功能实体，对外提供交互接口，并通过连接件将构件连接起来形成最终的软件架构描述。5个阶段是不断迭代的过程，在每一次迭代中，都选取并实现一组用例和场景来确认并完善架构。但是，架构师在设计时很难把握他的正确性和精准性，而且用它架构的系统是否对后续设计开发形成一种原则上的指导是很难说的。但是对于架构师来说有些思路可以进行参考，大致将架构思维可以分为：分解、集成、分离、复用、分层、模式、抽象、结构化、迭代、勿做过度设计这几部分，按照这个思维方式来设计系统架构。
分解，架构分解是架构师接到需求到完成架构设计中最关键的一步，分解可以帮助架构师了解需求中未呈现出来的隐性需求要素，分解也是架构师解决非功能层面需求的重要手段。例如多层架构、OSI 七层模型都体现了分而治之思想。在架构设计过程中，通过将关注点分离对架构进行多层次分解，将系统层层分解为多个架构元素，进而识别架构元素。同时保证分解后的各个部分还能够高内聚，松耦合，最终又集成为一个完整的整体。分解要遵循几个原则，
第一是业务原则：
-
单一责任原则：对于一个微服务而言，具有有限的业务范围，可以帮助我们满足服务开发和交付的敏捷性；
-
适当的边界：关注微服务的功能范围，一个服务的大小应该等于满足某个特定业务能力所需要的大小；
-
业务分层： 从整体规划上把业务分层，形成单向依赖，避免微服务之间的网状依赖关系；
-
颗粒度递增：设计初期先把业务划分到尽可能细，然后依据其它原则合并到适当颗粒度；
-
非唯一依赖：至少被2个以上其它微服务依赖的功能模块，才有必要独立成一个微服务。
第二是技术原则：
-
部署独立性：能独立于其它微服务部署，一个微服务故障不影响其它微服务；
-
动态扩展：每个微服务都可以动态的进行x轴和z轴的扩展，并适应云环境下的自动化部署；（ 参考这里 ）
-
领域和应用解耦：提供数据操作能力的领域服务和执行业务逻辑的应用服务解耦；
-
避免产生频繁的跨库查询；
-
避免产生频繁的分布式事务。
第三是治理原则：
-
在业务分层的基础上，根据业务细分规则，对微服务分组；
-
各个分组之间通过API网关集成；
-
通过API网关实现级轻量级消息路由，鉴权；
-
运行时管理，如服务降级，限流，监控等可在API网关实现，让微服务功能纯粹；
-
避免通过数据库集成；
-
避免部署多个版本来兼容。
在拿到一个系统后，在架构设计的初期我们肯定要经历一个不断探索的阶段，应用一个有效的架构分解模型来知道分解过程，非常必要，在文章中作者提到说依次从4个域中做架构的分解，基本顺序是先业务后技术，通过多维度多层次的分解将关注点分离，1业务域分解 2.业务功能域分解 3.技术域分解 4，涉众域分解
总之，分解是架构设计中的关键本周，架构分解没有成熟的方法体系来指导架构师，我们在今后的学习中，要多总结多思考，积累自己的经验