什么是架构师

架构师始终是一-个比较神秘的角色，就像架构一样，好像也没有一个定论。

每个人心中的架构师都是不一样的，并且有一一个规律，都把自己搞不定的事情交给架构师，以为架构师就是能搞定自己搞不定的事情的人。那什么是架构师呢?

全书总共33章的内容，大家转发关注小编，并且私信小编“学习”就可以拿到。

架构师做什么

做什么事决定了一个人是什么人。为什么我们称某个人为架构师，肯定是因为他在做可以被认为是架构师的事。那么哪些事是架构师应该做的呢?从前面我们所探讨的什么是架构可以看出:架构的目的就是为了增长。

而要达到增长，就必须要把很多人合并起来做同一件事情，并且使他们做的事情合并起来达到1+1>2的效果，最少也要达到1+1=2的效果。而在现实生活中，人数增长到了一定的程度，沟通效率就会下降。到了一定程度，人越多产出反而越少。

这个时候就需要架构师。

架构师会把需要增长的业务了解清楚，挖掘出核心生命周期，并确定核心生命周期的主体。换句话说架构师要发现问题的主体，并确定核心问题。在确定业务核心生命周期以及核心生命周期的主体之后，架构师还需要对业务核心生命周期进行分析，剥离出非核心生命周期，并根据当前人员的状况，合理地分配非核心生命周期的权责。这样不同的人就可以并行地互不影响地做不同的事情，最后根据核心生命周期，把他们的工作成果组合起来，达到1+1>2的效果。

以上仅仅是把现在的问题解决好，还需要更进一步，那就是根据对不同生命周期的运营情况，对未来的增长做一定的预判，提前做好规划，做相应的人员、技术的储备一这 就是战略架构。

业务、架构和技术三者的关系

某天和朋友吃饭正好聊到这个话题，作为架构师或者做技术的人，在开发软件时，他们基本就是在扮演上帝的角色:不但要创建出一个个的程序，还要让这些程序能够脱离他们在硬件上独立运行，以便为这个程序所服务的群体提供服务。

当这个程序出现问题或者错误(Bug )的时候，他们还要扮演牧师的角色，去修复这些问题。这不正是一个程序的社会吗?和人类社会的演变何其相似! 软件是模仿人类的，用人类演变的历史来指导软件开发工作是- 个很自然的想法，毕竟再次经历人类演变发展的历史是很痛苦的。架构师和程序员是决定软件的关键人物，可见架构师和程序员在扮演着多么重要的角色。

在软件设计开发的过程中经常 会看到，很多所谓的架构讨论实际上只是在讨论某些技术的技术讨论。在很多人看来，特别是软件工程师，架构和技术实际上是等同的。多学会了几种技术，就觉得可以做架构师了。或者学会的技术越多，就觉得自己的架构水平越高。

对于别的架构师当然也采用同样的标准来评判。要知道，任何技术都是为了解决某种问题而存在的，学会了很多技术，并不代表能够利用这些技术来解决问题。学会的技术的多少，所带来的差别只是解决问题的手段多了些而已。但是手段多了就一定是好事吗?学会的技术越多，很多时候越不知道采用哪种技术更好，所谓“乱花渐欲迷人眼"。

还有另一-种很普 遍的现象:做技术的软件工程师往往看不上业务。觉得技术更高端，而业务太平凡、太低端，并且业务人员总是给技术挖坑。而业务人员则觉得做技术的眼光高，但总是理解有偏差。技术人员往往对业务一知半解， 业务问题总是解决得不圆满。但业务人员对此又无可奈何，因为自己不懂技术。

业务、架构和技术三者都是软件行业从业者必须打交道的，这三个概念到底有什么异同?大家应该怎么处理业务人员、技术人员还有架构师的关系呢?

交易系统

交易系统是企业的核心系统，如何建设好交易系统是一个很有趣的话题。通过对交易系统的分析，可以看到社会发展对软件的影响，以及软件架构是如何在软件中发挥作用的，同时软件又是如何反过来推动社会发展的。

对于交易系统，不同类型的企业各有其不同的特质。制造业类的企业以制造为主，交易往往较弱，总是依赖于渠道类的企业帮助售卖。因此渠道类的企业往往是软件虚拟化的先导，而且以交易为主项。无论是哪种企业，交易系统都是大同小异的，因为其核心生命周期都是一样的， 都是服务于交易双方的。

各种交易系统的区别在于企业的产品不同，售卖的流程也不一样。不同交易系统的最终目接下来就通过对交易系统的分析，忽略不同企业的交易系统之间行为的差异，从交易系统本身的职责拆分和架构的拆分中，展现架构是如何在软件中应用的。

大家转发关注小编，并且私信小编“学习”就可以拿到。

每一个人对架构都有不同的概念和理解，那你对架构是怎么理解的呢？欢迎大家讨论。