软件架构分解后记

　

  <<软件架构分解>>一文在IBM developerWorks中国网站发表后，得到较多外界关注，包括业界知名的InfoQ网站和多个其他网站的转载，阿里同学以及其他公司的同行也有兴趣做交流，具体见博文底部截图。

 

    核心内容3年前在阿里巴巴工作时给少部分人分享过，这次发表对内容进行了充实，补充了一些图片，以便更好理解。

 

　 庖丁解牛的故事绘声绘色地描述了庖丁高超娴熟的解牛技能。技进于道，庖丁在解牛的实践中，已经超越了解牛的技能层次，由具体的技术升华到道或艺术的层次，悟到了解牛之道。道在日用，任何行业中都有道，就看你能否悟道。软件架构分解同样也存在从术到道的超越，哪软件架构分解的’解牛‘之道是什么？

     答案可以用一句话来概括，那就是多维度多层次的立体分解。例如我们可以按业务维度、涉众类型(和你关注的系统有关联的用户和其他系统)维度、请求类型维度(请求类型有多种分类方式，一种是按读或写来分类，此时我们分解的结果就是读写分离）、性能维度、系统逻辑层次(例如前台、后台等)维度等。

    分解维度的识别，如果哪个维度成为你关注的重点或痛点，那它就可作为分解的候选维度。

 

    文章主要内容：提出了架构作用力的概念和架构本质论、软件架构分解过程框架、多维度多层次分解模型。不局限在软件领域，关于架构的本质，有的认为架构的本质是对系统复杂性的掌控，这个也不完全对，并且这种看法还是偏向于形而下的一种认识。难道相对简单的系统或事物就没有架构？即使简单的系统和事物也存在合适/合理的架构或结构，此时架构对复杂性的掌控何在？此时的架构本质可能体现在结构体各部件间的和谐、平衡和简洁之美。

 

　 涉众就是UML Use Case中的Actor，在一个系统中存在多种涉众，例如系统用户、投资者、需求分析师、架构师、开发人员、测试人员、客服人员、运维人员等等。涉众也可以是和系统交互的外部系统。

 

　这里的涉众概念是广义的有层次的，当对一个架构元素进行架构设计时，例如某子系统，则和该子系统有交互的其他子系统或外部系统也可认为是该子系统的涉众。对各种约束，其来源方（他们通常制定或产生约束）也可以认为是涉众。

 

　这些涉众在架构层面有各自的架构需求（关注点），例如投资者关注成本和上线时间；开发设计人员希望系统架构清晰，便于理解，关注代码重用性、扩展性、可维护性。架构师更关注系统可伸缩性、可用性、性能等质量需求和各种约束（技术约束、法律法规合规性约束等）。这些需求和约束必须在架构层面加以考虑，结构决定功能是自然界的普遍法则，在软件架构领域，这些需求和约束也必然要在软件架构上得到体现，从而使这些涉众的需求在架构层面得到足够的满足。

 

　软件架构中的各个架构元素（子系统、模块等）是如何识别产生出来的？分解是一种识别架构元素最常用的方法之一。罗马不是一天建成的，对复杂的软件系统，其架构设计通常不可能一蹴而就，遑论架构演化。对复杂的软件系统进行架构分解，需要有经过验证的方法论来指导，这篇文章提出了一个架构分解的过程框架，并进一步阐述了如何进行架构分解以及迭代和演化，主线是从业务架构出发，先梳理好业务架构,包括业务流程、业务边界上下文和其包含的业务功能、业务领域模型、业务逻辑业务规则、业务战略、组织架构和业务涉众。再从业务架构主要是粗粒度的业务边界上下文映射出初步的应用架构，应用架构用来支撑和实现业务架构业务功能，也就是通过这些应用之间的协作来实现业务功能，此时的应用架构中很少有技术的成分在内，一些应用可能还需要进一步拆分。接下来深入到应用架构中的每个应用内部进行技术实现，考虑非功能需求，加入技术上的架构元素，例如数据库、缓存、技术基础设施、分层服务等，产生技术架构包括数据架构，技术架构用来落地应用架构。总体而言就是从业务架构到应用架构，再到技术架构，一步步逐步充实、丰富、完善，像一颗缺少枝叶的小树一样，逐渐越长越大，枝叶越来越多，最后成为一颗枝繁叶茂的大树，最终产生软件系统架构。

 

 分解的粒度不是越小越好，是综合权衡下的适当粒度的分解，分解为微服务不一定合适，很多中小公司的系统就不适合。分解可能是逻辑上的，也可能是物理上的。

 

　软件架构设计除了分解还有组合(集成)，分解主要是自上而下的，而组合是自下而上的。在实际的架构设计过程中，它们通常是互相交融相互结合进行的。

 

　科学最终会上升为哲学，哲学的终极就是道，在软件架构形而下的定义之外，上升到更高的抽象层次，对架构（不止局限于软件架构）形而上的本质也做了一些探讨。

 

　具体内容详见IBM developerWorks上的软件架构分解。IBM已将该文作为新兴技术大学的学习课程，见IBM新兴技术大学课程链接。阿里巴巴的同学有兴趣做交流，如下图。infoQ网站上也有相应的介绍，见链接https://www.infoq.cn/article/2014/03/linkedin-log-arch-weekly

 

 

      阿里同学的交流请求：