谈谈我理解的SA——Systems Architecture
SA即Systems Architecture，是系统体系结构。
系统体系结构是定义系统的结构、行为和系统视图的概念模型。架构师将其系统的形式化描述或表示出来，以支持结构和行为的推理的方式组织。
谈起SA，我第一印象总觉得他是一个概念，一个混淆的概念，因为他被提出时就是模糊的。然而随时不断的接触，它其实是会越来越清晰的出现在我们眼前，他是那么的有条理，那么的明确，甚至连动态变化都可以被用文字语言描述。
我看过一些架构相关的书籍，然而大部分书中描述的内容都是一种作者最熟悉，或者自己创新的结构。当然，它们很有用，但某一种结构或几种组合都不能代表SA，它们只是SA繁衍出来的具体行为的指导思想或结构模板。
ABSD(architecture-based softwar design)基于体系结构的软件设计。ABSD方法是一个【自顶向下】，【递归细化】的方法。ABSD把整个基于体系结构的软件过程划分为体系结构需求、设计、文档化、复审、实现、演化6个子过程。
什么意思呢？就是在做架构时，有一个正常的顺序：
【需求=>设计=>文档化=>复审=>实现=>演化】
这是一个自顶向下的顺序，但节点之间和节点内部还存在递归，并且每个节点都有自己独特的细化方案。
有兴趣的同学可以百度了解一下ABSD。或者买些相关书籍。
为什么推荐ABSD呢，因为我觉得大多数系统结构，都是基于ABSD扩展的。学会ABSD以后，在阅读其他相关书籍时，会事半功倍。
SA并不是只有思想，在实践的过程中，我们还要设计或者选择框架，在ABSD中，SA被被分为三个基础元素，分解、风格、模板。然而我觉得风格和模板可以合并，改称为框架，相信很多架构师都有自己的框架，而且可能有很多个框架。
SA实践时，有很多种方法，步骤也可以不同，书上的概念总是希望将很多内容归纳或归类为一；然而现实中，我们在实现SA时，往往是设计与框架同时进行。所以我觉得实战中，大部分架构师的设计顺序应该是这样的。
一，分解子系统和功能模块；
二，设计框架模型；
三，分析功能模块；
四，设计框架详细。
然而现实中不会有这么清晰的边界，真实的情况可能是，这四步也相互穿插，同步进行。
这是个很有趣的问题，因为很多人都在用学习，创新SA，他们在尝试为它定义的同时，还尝试将软件设计模式，软件开发方法，软件管理方法，软件风格，软件模板等等概念与SA进行分离，并逐一明确其概念和实现。
虽然细节很重要，没有细节的SA都是空谈，但如此多的书籍和定义，导致的结果就是，很多人在学习时，需要面对茫茫多的概念，找不到总纲，然后混乱的一沓糊涂。
我突然想起了王阳明先生的“知行合一”；知行本是一，却被拆分为二，圣贤教人知行，却被后人传为知与行。
我觉得软件概念目前也存在着这样的情况。例如XP极限编程，如此详细的构建了开发细节，明明是SA的一种，可却被定义为软件开发方法，看起来好像XP和ABSD和ADMEMS是不同的东西了。
为什么呢，因为很多SA的书籍在编写时，有些书想重点突出设计思想，因为他觉得那是他的亮点，而人员分配，设计模式，并未提及。但依据其思想其实是可以推理出开发测试分工的。再比如，XP重点突出其特殊的人员配置和分工模式，但其分布式模块，独立设计的设计思想也是跃然纸上。
【PS：但如果你都能依据他的书中的部分内容，推理出整个SA细节，那我觉得你也不需要看他的书了。】
回到现实中，在茫茫的网络世界里，我们只是因为其突出的侧重点不同，而强行将其分类定义，只是增加后学的学习难度和成本，而已。
架构重点关注问题
理解系统要解决的问题
认识系统特性与要解决的问题间的关系
识别系统的核心行为
整理系统的非功能性需求
确定架构需求
管理需求
规划系统的高层组织
确定架构机制
分析用例场景
演进系统的高层组织并形成组件模型
规划系统的运行时架构和部署模型
规划系统的实现模型
编写核心代码
验证架构设计
整理架构文档
----------------------------------------------------------------------------------------------------
注：此文章为原创，任何形式的转载都请联系作者获得授权并注明出处！
若您觉得这篇文章还不错，请点击下方的【推荐】，非常感谢！
