这篇文章讲述了架构设计的思维是怎样的，对我这学期的软件体系架构有了一个概括的描述。一个经典的架构设计过程模型，沿用了RUP中迭代增量的思想，由分析、描述、选择、构造和组合5个阶段组成，如图：
这个过程模型看似很流畅，但是，架构师在设计时很难把握他的正确性和精准性，而且用它架构的系统是否对后续设计开发形成一种原则上的指导是很难说的。但是对于架构师来说有些思路可以进行参考，大致将架构思维可以分为：分解、集成、分离、复用、分层、模式、抽象、结构化、迭代、勿做过度设计这几部分，按照这个思维方式来设计系统架构。作者先介绍了分解的架构方法。
- 架构分解的作用：架构分解是架构师接到需求到完成架构设计中最关键的一步，分解可以帮助架构师了解需求中未呈现出来的隐性需求要素，分解也是架构师解决非功能层面需求的重要手段，架构要解决高性能、高可用、伸缩性、可扩展性等问题，
- 分解的原则
（1）业务原则
单一责任原则：对于一个微服务而言，具有有限的业务范围，可以帮助我们满足服务开发和交付的敏捷性；
适当的边界：关注微服务的功能范围，一个服务的大小应该等于满足某个特定业务能力所需要的大小；
业务分层： 从整体规划上把业务分层，形成单向依赖，避免微服务之间的网状依赖关系；
颗粒度递增：设计初期先把业务划分到尽可能细，然后依据其它原则合并到适当颗粒度；
非唯一依赖：至少被2个以上其它微服务依赖的功能模块，才有必要独立成一个微服务。
（2）技术原则
部署独立性：能独立于其它微服务部署，一个微服务故障不影响其它微服务；动态扩展：每个微服务都可以动态的进行x轴和z轴的扩展，并适应云环境
领域和应用解耦：提供数据操作能力的领域服务和执行业务逻辑的应用服务解耦；
避免产生频繁的跨库查询；
避免产生频繁的分布式事务。
（3）治理原则
在业务分层的基础上，根据业务细分规则，对微服务分组；
各个分组之间通过API网关集成；
通过API网关实现级轻量级消息路由，鉴权；
运行时管理，如服务降级，限流，监控等可在API网关实现，让微服务功能纯粹；
避免通过数据库集成；
避免部署多个版本来兼容。
3.架构分解
架构分解过程如下图所示，是一个迭代的模型。通过这个迭代的分解，从无到有、从粗到细、从模糊到清晰，一步步精（细）化、丰富架构。迭代的过程也是一个否定之否定的过程，随着分解的逐步推进或系统的架构演化，后面的分解除了会识别出隐性需求，也可能会对先前识别出的架构作出调整。
4.分解维度
架构分解就是从多个维度多层次对系统进行分解，识别出架构元素，逐步精化、丰富系统架构的过程。从上面可以总结出，纬度大致有，业务纬度、业务功能纬度、技术纬度，涉众纬度。
5.分解力度
多维度多层次分解到什么粒度才停止？这个没有统一的标准，通常要能进行并行开发，能指导后续的详细设计。需要根据具体的产品或项目来定，有的到模块级别就行，对关键的部分，可以到类级别。
6.分解时机
架构分解的时机通常就是架构改造演化的时机。当架构出现腐化和臭味，已经难以满足关键涉众的关键需求，例如用户的响应速度越来越慢已经接近临界值，并且根据预见，响应速度还有可能继续较低；开发人员越来越难以维护，这个时候可以考虑进行架构演化，对架构进行改造。当然如果能提前预见系统的问题，经过慎重评估后，在问题发生之前，提前一段时间进行架构演化也是可以的。
分解作为架构设计中关键的步骤，这片问斩更是我了解的架构分解的作用，原则，维度，分解时机。让我感觉到系统架构还是比较难的，并且需要长时间的时间类积累这些经验并且把他们应用在项目之中。