软件架构分解

　初稿在７月提交，12月中旬收到IBM的邮件通知说已经发表在IBM developerWorks中国网站。核心内容在3年前给少部分人ppt分享过，这次发表对内容进行了充实，补充了一些图片，以便更好理解。

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

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

　 在一个软件系统中存在多种涉众，例如系统用户、投资者、需求分析师、架构师、开发人员、测试人员、客服人员、运维人员等等。

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

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

　软件架构中的各个架构元素（子系统、模块等）是如何识别产生出来的？分解是一种识别架构元素最常用的方法之一。罗马不是一天建成的，对复杂的软件系统，其架构设计通常不可能一蹴而就，遑论架构演化。对复杂的软件系统进行架构分解，需要有经过验证的方法论来指导，这篇文章提出了一个架构分解的过程框架，并进一步阐述了如何进行架构分解以及迭代和演化，从而逐步充实/丰富软件架构。

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

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

　具体内容详见IBM developerWorks上的软件架构分解链接。IBM已将该文作为新兴技术大学的学习课程，见IBM新兴技术大学课程链接。infoQ网站上也有相应的介绍，见链接http://www.infoq.com/cn/news/2014/03/linkedin-log-arch-weekly