任何做要是想做从技术方向发展的程序员来说，都想成为架构师，那是几乎是技术的巅峰状态。但要成为一个架构师，并不是那么容易，光对现在流行的框架的深入理解，就已经让人头疼了，熟悉优秀的软件框架设计，能够帮助更好的设计架构，同时在业务方面，在某一个领域虽然不是完全必要的知道一些细节，但至少也能识别业务的风险，以及业务的大概逻辑，这些下来，一般的架构师，至少也得5年以上的工作经验，才能在业务上和技术上有一定的熟练度。但在立志成为架构师之前，必要的就是确定架构师的方向，慢慢的往它靠近，不然多年努力下来，却发现做了好多的无用功，在战术上的勤奋掩盖不了在战略上的懒惰，所以即便现在还没有达到架构师的水平，但至少也得知道架构师是什么样子？
作为一个软件架构师，他的工作主要是设计软件的整体架构体系，将需求转换为软件的超前操作，而进行这个超前操作的好处就在于，能够尽早的对软件体系风格进行确定，规范后续的开发，同时确定软件的开发过程，降低开发或者投产后软件的质量风险，提高系统的性能。可以说软件架构设计的适用性，将直接影响软件的整体性能。而设计软件体系架构的，就是要根据需求模型，对软件进行架构设计，主要包括以下几个行为。
1.需求抽象
在需求过程中，我们会得到一个软件需求规格说明书，该文档详细的说明了该软件要实现的功能以及他的细节流程，每个功能都是相对分散叙述的，即便在一开始，我们可以有目的的将一些物理上关联的功能叙述规范到一个模块当中，但该需功能上的划分只能给软件的架构设计作为一个参考，既是对软件的模块进行一个大概的设计，我们还需要的是对需求功能进行划分，该划分应该是综合考虑业务和技术的划分，总的来说，可以分为过程抽象和数据抽象，过程抽象是在模块化抽象的基础上对模块与模块之间的过程进行抽象，从而抽象为一个更为紧密的系统，数据抽象则是对模块对外的数据进行抽象，得到一个大的抽象，每个模块之间的关系就构成了软件架构的关系，如何定义和在什么视角上看待这几种数据将直接影响架构的设计。
2.架构体系风格选择
需求抽象主要是为了实现从需求文档到技术构建的理解，通过对需求的抽象，我们能够得到软件的可能的几个模块，以及模块之间可能的关系，在此基础上，对软件架构风格进行一个简单的确定，此步骤应该并不是必须的，但在一开始定义有助于后续开发的稳定，虽然很多时候架构风格并不是一层不变的，大都数都是几种风格配合应用，相对比较灵活，这些都可以在以后的工作中慢慢的加入。一般的软件架构风格有：面向对象，层级风格，数据流风格，调用返回风格。不同的风格他的实现方式也不尽相同，也各有各的优缺点，这些也是比较传统的体系风格了，有些比较现代的风格，基于这几种风格的改编。
3.模块化
确定了软件体系风格后，针对不同的风格，他的模块化方式也不同，所以在此基础上也要对模块进行重新的定义，当然改动的越小越能够贴近原业务，另外有些软件体系风格，可能需要定义一些基础技术模块来支持业务模块，这些就又增加了模块的负担，这跟体系风格的选择有关，所以选择要慎重。而模块化的过程就是根据不同的风格，对模块的借口以及对外公布的属性进行定义，以及对模块在系统的业务位置进行定义，这个过程需要不断的迭代完成，甚至包括整个架构设计都需要迭代完成，因为在前期对整体实现方案还没有最好的展现之前，很多设计都可能会被推倒重来，所以要时刻的保证每个决策都是正确的，或者对每个决策进行记录，以保证能够回退到上一个设计。不同的风格的设计对模块化的影响，举个例子，比如层次风格，该风格将软件的分为几层，最里层是核心系统，软后越往外系统就越是跟外部用户相关，所以这种设计风格，对模块的要求就是首先要找到核心系统，然后逐渐的一层层的剥业务逻辑，比如我们常用的mvc框架，就是基于这个原理。当然其他风格也会有其特有的设计风格。
4.模块细化
当确定了系统的中每个模块后，才开始确定每个模块怎么实现其功能，包括一些功能的细分和一些业务的剥离设计，模块的细化，同时也可以对模块进行结构设计，可以保持原软件风格，也可以定义其他风格，但总体来说，如果一些风格不支持这种变化，只能统一成一个风格的模块风格，模块细化，主要是根据业务和整个模块的定义，对模块的过程和属性进行设计。
5.描述系统实例
转换为可输出性文档。
到此，软件的架构设计过程也基本完成，只有5步，但他的工作量实际上巨大的，以及需要很多的经验和知识的支持，每一个步骤都需要工程师的专业能力，对技术的理解，对现代软件体系结构的认识，以及对软件系统与业务的关系的理解，与计算机的关系等等，可以说，架构师是综合了技术和业务的人。
网友评论