架构阅读笔记9
技术需求分解：是从技术角度对系统和模块进行分解。在该阶段，通常会选取关键的需求（包括功能需求和非功能性需求）和已分解出的模块或子系统，结合当前的 IT 技术（技术框架、架构模式、参考架构、中间件、业务平台）和架构思想、架构经验、开发人员的技能以及系统的上下文环境等，进一步进行架构分解。
在技术需求分解中，对功能需求，横切（分层）竖割分解手法。对非功能需求，可将性能、伸缩性、可用性等作为维度对系统进行分解。
在技术需求的分解中，对公共的技术需求应全盘考虑，抽象出底层的公共技术基础设施，可能会采用一些成熟的框架和中间件技术，如消息中间件、RPC等。
技术需求分解一方面来源于问题域的本质复杂性，特别是各种非功能性需求的复杂性，另一方面也是由于互联网技术的日新月异，要求架构师对技术敏感，与时俱进。当在技术域分解中碰到困难时，可以再回到业务域中去寻找答案和线索。
架构需求分解：全面考虑各类涉众在架构层面的关键需求，特别是非功能需求，例如性能需求、可伸缩性需求等，进一步对系统进行分解。
架构分解就是从多个维度多层次对系统进行分解，识别出架构元素，逐步精化、丰富系统架构的过程。纬度大致有，业务纬度、业务功能纬度、技术纬度，涉众纬度。
根据具体的系统，还可发掘出许多分解维度，如时间维度、物理空间维度、优先级维度、职责角色维度（不同的角色）、客户端维度、调用方维度（不同的调用方）、请求类型维度、数据维度、数据处理维度等。
对非功能需求特性的架构模式或架构策略成为战术，例如，对可用性，战术为冗余、错误检测。
对于分解的粒度，没有统一的标准，通常要能进行并行开发，能指导后续的详细设计。需要根据具体的产品或项目来定，有的到模块级别就行，对关键的部分，可以到类级别。
架构分解的时机通常就是架构改造演化的时机。当架构出现腐化和臭味，难以满足关键涉众的关键需求，例如用户的响应速度越来越慢已经接近临界值，并且根据预见，响应速度还有可能继续较低；开发人员越来越难以维护，这个时候可以考虑进行架构演化，对架构进行改造。当然如果能提前预见系统的问题，经过慎重评估后，在问题发生之前，提前一段时间进行架构演化也是可以的。
注意的问题是不要过度分解，过早分解，这样做除了增加成本，还可能带来风险。例如很多系统在建设初期，考虑到规模较小和快速上线，通常都是一个整体的系统，不会进行大的架构分解，以后随着需求和规模的逐渐增加，会逐步进行架构改造和架构分解。