一直以来，作为一名软件工程师，都十分向往“架构师”的名号，也一直奋斗在通往“架构师”的路上。但如果要是问他们：什么是架构师？往往每个人回答的都千奇百怪，也就是说在每一个人的心里对架构师的认识都互不相同。有的人说，架构师要掌握很多的技术。也有的人说，架构师不必到细节，要宏观把控。还有的人说，架构师要有超强的预知能力。等等。就如同盲人摸象，“架构师”一词太大、太笼统了，如果仅是站在自己认为的角度来看，很难准确定义出“什么是架构师”。
其实“架构”不是软件行业的专有名词，在软件行业很早之前，架构就已经存在了，比如：建筑行业等。所以“架构”并不是局限在某一行业中，反而它存在于整个人类社会的高效协作之中。要真正的去理解架构，并不能局限于软件行业之中，当然了后续会重点讲述软件行业中的架构。
面对“架构”一词，空杯心态，从起源开始分析“架构”的诞生。为何空杯心态，暂时放弃之前自己认为对架构的认知，从“架构”由无到有的诞生角度来认知，之后再和自己之前的认知，进行碰撞纠正吧。
本文将先从“人”、“组织”、“社会”三个方面来讨论架构为何产生、架构为何物、应该如何去做架构？最终会在“软件”行业方面，根据对架构的认知，来实施架构的落地。
从远古谈起
-
在远古早期，每个人都完全独立生活，衣、食、住、行等等全部都自己搞定，整个人类都是独立的个体，不相往来。为了解决人类的延续的问题，自然而然就有男女群居出现，这个时候就出现了分工了，男性和女性所做的事情就会有一定的分工，比如：男性身体强壮擅于捕猎、女性性情温和善于孕育等。可是人每天生活的基本需求没有发生变化，还是衣食住行等生活必须品。
面对问题：人类延续；
架构形成：男女群居、男女分工；
-
然而面对自然灾害，生活遭受灾害不确定性，所以多人分工配合作为生存的整体，力量就显得强大多了，所以也自然的形成了族群：有些人种田厉害，有些人制作工具厉害，有些地方适合产出粮食，有些地方适合产出棉花等，就自然形成了人的分群，地域的分群。当分工发生后，实际上每个人的生产力都得到了提高，因为做的都是每个人擅长的事情。
面对问题：自然灾害、个人生产效率低，生活遭受灾害不确定性；
架构形成：多人族群，角色分工；
-
整个人群的生产力和抵抗环境的能力都得到了增强。为什么呢？因为每个人的能力和时间都是有限的，并且因为人的结构的限制，人同时只能专心做好一件事情，这样不得已就导致了分工的产生。既然分工发生了，原来由一个人干生存所必需的所有的事情，就变成了很多不同分工的角色合作完成这些事情，这些人必须要通过某些机制合在一起，让每个人完成生存所必需的事情，这实际上也导致了交易的发生。
面对问题：由于角色分工导致，个人不能生产出生活所有必须品；
架构形成：交易系统、交易货币；
-
在每个人都必须自己完成所有生活必须品的生产的时候，是没有架构的（当然在个人来讲，同一时刻只能做有限的事情，在时间上还是可能会产生架构的）。一旦产生的分工，就把所有的事情，切分成由不同角色的人来完成，最后再通过交易，使得每个个体都拥有生活必须品，而不需要每个个体做所有的事情，只需要每个个体做好自己擅长的事情，并具备一定的交易能力即可。
角色分工产生，生产力提高，更需要具备的是交易沟通能力。只有交易沟通，才能使每个个体拥有生活各方面的必须品。
经过上面四步，这实际上就形成了社会的架构。那么怎么定义架构呢？以上面这个例子为例，把一个整体（完成人类生存的所有工作）切分成不同的部分（分工），由不同角色来完成这些分工，并通过建立不同部分相互沟通的机制，使得这些部分能够有机的结合为一个整体，并完成这个整体所需要的所有活动，这就是架构。
五个动力条件，通过以上的例子，可以归纳出产生架构的五个动力条件：
- 必须由人执行的工作（不需要人介入，就意味着不需要改造，也就不需要架构了）；
- 每个人的能力有限（每个人都有自己的强项，个人的产出受限于最短板，并且由于人的结构限制，同时只能专注于做好一件事情，比如虽然有两只眼睛，但是只能同时专注于一件事物，有两只手，无法同时做不同的事情。ps. 虽然有少部分人可以左手画圆右手画框，但是不是普遍现象）；
- 每个人的时间有限（为了减少时间的投入，必然会导致把工作分解出去，给擅长于这些工作的角色来完成，见2，从而缩短时间）；
- 人对目标系统有更高的要求（如果满足于现状，也就不需要进行架构了）；
- 目标系统的复杂性使得个人无法完成这个系统，满足条件2，3（如果个人就可以完成系统的提高，也不需要别的人参与，也就不需要架构的涉及，只是工匠，并且一般这个工作对时间的要求也不迫切。当足够熟练之后，也会有一定的架构思考，但考虑更多的是如何提高质量，提高个人的时间效率）；
有人可能会挑战说，如果一个人对目标系统进行分解，比如某人建一栋房子，自己采购材料，自己搭建，难道也不算架构嘛？如果对于时间不敏感的话，是会出现这个情况的，但是在这种情况下，并不必然导致架构的发生。如果有足够的自觉，以及足够的熟练的话，也会产生架构的思考，因为这样对于提高生产力是有帮助的，可以缩短建造的时间，并会提高房子的质量。
当这5个条件同时成立，一定会产生架构。从这个层面上来说，架构是人类发展过程中，由懵懵懂懂的，被动的去认识这个世界，变成主动的去认识，并以更高的效率去改造这个世界的方法。
架构本质是什么
- 根据要解决谁的问题，对目标系统的边界进行界定。
- 并对目标系统按某个原则的进行切分。切分的原则，要便于不同的角色，对切分出来的部分，并行或串行开展工作，一般并行才能减少时间。并对这些切分出来的部分，设立沟通机制。
- 根据3，使得这些部分之间能够进行有机的联系，合并组装成为一个整体，完成目标系统的所有工作。
同样这个思考可以运用到其他行业架构，比如：企业架构、组织架构、软件架构等等。每一次架构的变革，都是主动对现有问题的解决，对现有环境的适应。
架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，并进行分解、合并，解决这个问题的实践活动。
架构的产出物，自然就是对问题的分析，以及解决问题的方案：包括拆分的原则以及理由，沟通合并的原则以及理由，以及拆分，拆分出来的各个部分和合并所对应的角色和所需要的核心能力等。
概念认知
架构实际上是解决人的问题，而概念是人认识并沟通这个世界的基础，自然概念的认识就非常的重要。
举个栗子：
比如说“什么是桌子？”其实每个人对其的理解描述都是千奇百怪的，这实际上就导致了做架构的时候，不同角色的沟通会出很多问题，那么结果也就可想而知了。
所以，在架构中对概念的认知，其实是很关键的。那为什么每个人对概念的理解会千奇百怪呢？其实大部分人对于每天都习以为常的概念，都自以为明白了，实际上都是下意识的认识，并不是主动的认识。所以，对于概念，作为架构师应该主动地进行思考认识。
在古代，概念不叫“概念”，称之为“名相”。
何为相？
一般我们认为：看到一个东西，比方说杯子，“杯子”就是一个名字，指代的看到的东西就是相，就是事物的相状。我们一听到“杯子”这个词，脑海里就会浮现出一个杯子的形象。而“杯子”这个词，是用来指代的是这个相状的，叫做名。合起来就叫做“名相”。
可是当我们把杯子打碎了的时候，我们还会称这个碎了的东西叫杯子吗？ 肯定不会，一般会叫“碎瓦片”，如果我们把碎瓦片磨碎了呢，名字又变了，叫做“沙子”。这就奇怪了，同样一个东西，怎么会变出这么多的名字出来？
实际上“相“表达的不是一个具体的东西，如上面所提的一个瓷器杯子，并不是指这个瓷器，而是这个瓷器所起的一个作用：一手可握，敞口（一般不超过底的大小，太大口就叫碗了），并且内部有一个空间可乘东西的这么一个作用。并不是指这个瓷器本身。这也是为什么我们从电视上看到一个人拿杯子的时候，我们知道这个是杯子。但是实际上我们看到的都是光影而已。所以说相实际上代表的是这个作用，并不是具体的某个东西，而名是用来标识这个作用的，用来交流的。
所以，其实杯子在打碎、磨碎的过程中，其实作用也被改变、破坏了，自然相也就被改变了，随之而来，名也就发生了改变。
那为何需要这个作用？
这个作用其实是为了解决人的问题：“人需要一个可单手持握，但是希望避免直接接触所盛物体”。
所以说，每个概念实际上背后所解决的，还是人遇到的某个特定的问题，我们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。对于概念这个词本身，为了统一指代这些名字，我们称起这类作用的名字称为“概念”。
同理，为何我们可以在不同的语言间进行翻译，是因为虽然语言不同，但是人类所面临的的问题是一样的，所使用的名不同而已。对于不同的动物之间的翻译也是同理。
何为抽象？
抽象这个词代表的含义，实际上是把不同的概念的相似的部分合并在一起，形成一个新的概念。
这个里面问题很多：首先“相似的部分”在不同的人看来，并不一定那么相似；其次，抽象之后形成的是一个新的概念，和原来那个概念并不一样，所解决的问题也不一样。所以我们不能用抽象来定义一个事物，抽象实际上是一个分类的过程，完全是另一码事。
再举一个例子，杯子和容器，很多人认为容器是杯子的抽象，但是实际上杯子是杯子，容器是容器，它们所解决的问题是不一样的。当我们需要解决装东西的问题的时候，会说容器；当我们需要解决单手持握要装东西的时候，会说要一个杯子。
回过头来，根据架构的定义，要做好架构所首先必须具备的能力，就是能够正确的认识概念，能够发现概念背后所代表的问题，进而才能够认识目标领域所需要解决的问题，这样才能够为做好架构打好基础。
对上述内容，总结一下：
相是一个具体物体的状态和作用，是来解决具体人的问题。而为了人之间的交流，便根据相有了名，名其实就是一个标记，或理解为简单的概念。所以概念的背后其实是代表解决人的问题。
而抽象则是对概念或名相似之处的归类、分类的过程，不同角度来看会得出不同的相似之处，从而会有不同的抽象出来，所以抽象也会产生不同的新的概念。但抽象出来的概念不能够指具体的事物，而只能做到泛指一类具有相似之处的事物。其实抽象本身也是一个概念，其背后也在解决归类，分类的问题，但抽象并不是架构的必然产物。
而在解决问题的工程中，会首先有简单名相（意指解决问题的最原始工具或物体），遇到更高级问题，会有更高级的名相或概念，通过抽象，对名相进行归类、分类，抽象出新的概念，或者再有更高级的抽象，产生更高级的概念，最后由这些概念会组成架构。
问题识别
按照上面的架构定义，架构就是要不断解决人遇到的问题，然而做好架构首先需要做的就是识别出需要解决的真实问题。一般来说，如果把真正的问题能够找到，那么问题就已经解决了80%。这个能力基本上就决定了架构师的水平。
那么如何识别出需要解决的真实问题呢？
- 识别问题主体
- 识别问题边界
如何识别问题主体呢?
所有的概念基本都有一个很大的问题，就是缺乏主语。而我们大家都心照不宣的忽略这个主语，沟通的时候也都以为大家都懂得对方说的主语是谁，结果大家都一起犯错误。识别问题的一个最大的前提就是要搞清楚：是谁的问题。这个搞清楚了，问题的边界也就跟着确定了，再去讨论问题才有意义。
当我们处理问题的时候，如果发现自己正在致力于把自己的工作完成，要马上警惕起来，因为这样下去会演变成没有ownership的工作态度。在面对概念的时候，也会不求甚解，最终会导致没有真正的理解概念。
作为软件工程师或者架构师，我们大部分时候是要去解决别人的问题，“别人”是谁，是值得好好思考的。应该问的第一个正确的问题就是：目标问题是谁的问题。
如何识别问题边界呢?
明白了问题的主体，这个主体就自然会带来很多边界约束。我们一定要明白，任何找上架构师的问题，绝对都不是真正的问题。为什么呢? 因为如果是真正的问题的话，提问题过来的人肯定都能够自己解决了，不需要找架构师。架构师都要有这个自觉：发现问题永远都比解决问题来的更加重要。
当明白了问题的主体，我们才可能真正的认识问题是什么。因为问题的主体是问题的隐含边界，边界不确定下来，问题就是不确定的。一旦确定了主体，剩下的就是去搞明白主体有哪些问题。
一般来说，从问题暴露的点，一点点去溯源查找，一定会找出来谁的问题，以及是什么问题。当问题的主体离架构师越远，就会让找出问题主体的过程越加困难。最坏情况就是当我们时间或者能力有限，实在是无法定位出是谁的问题的时候，比如系统出故障，也就意味着我们无法根本解决问题。这时最好的办法就是去降低问题发生所带来的成本，尽量去隔离问题影响的范围。给我们留出时间和空间去识别真正的问题。
总结一下，要正确的认识问题，需要问两个问题：
- 这是谁的问题？
- 这有什么问题？
当得到的回答是支支吾吾的时候，我们就知道正确的方向在哪儿，以及需要做哪些事了。问题1会花比较多的时间，也是支支吾吾最多的地方，因为架构要解决的问题都是人的问题。但是一旦确定了答案，问题2就会变得非常容易。可以这样说，架构师的能力大部分会体现在问题1的识别上。
在实际工作中存在很多的情况，都只是在完成自己的问题或任务，而忽略了问题或任务的根本：谁的问题、什么问题。作为架构师，不仅是架构师，在面对问题时，而要更多的找出问题是什么，问题的主体是什么，从而只有有了主体，才能够确定问题的边界，最终才会确定出真正的问题所在。
架构切分
既然现状存在问题，识别到真正问题之后，需要面临的就是要解决问题。需要做现状的调整，那么就必须要有所动作，做相应的调整。这个调整就是架构的切分。
要非常的清楚，所有的切分调整，都是对相关人的利益的调整。我们已经知道，随着社会的发展，分工是必然的，为什么呢?这个背后的动力就是每个人自己的利益。每个人都希望能够把自己的利益最大化，比如：生活的更舒适，更轻松，更安全，占用并享有更多的东西。但是每个人的能力和时间都非常的有限，不可能什么都懂，所以自然需要舍掉一些自己不擅长的东西，用自己擅长的东西去换取别人擅长的东西。
对比一个人干所有的事情，结果就是大家都能够得到更多，当然也产生了一个互相依赖的社会，互相谁都离不开谁。这就是自然而然而产生的架构切分，背后的原动力就是人们对自己利益的渴望。人们对自己利益的渴望也是推动社会物质发展的原动力。
在这个模式下，比较有意思的是，每个人必须要舍掉自己的东西，才能够得到更多的东西。有些人不愿意和别人进行交换，不想去依赖于别人，这些人的生活就很明显的差很多，也辛苦很多，自然而然的就被社会淘汰了。如果需要在这个社会上立足，判断标准就变成了：如何给这个社会提供更好更有质量的服务。提供更好的更多的服务，自然就能够换取更多的更好的生活必需品。实际上这就是我们做人的道理。
那么现状中一般会存在什么问题？
当人们认识到要主动的去切分一个系统的时候，毫无疑问，我们不能忘掉利益这个原动力。所有的切分决策都不能够违背这一点，这是大方向。结合上一篇“识别问题”，一旦确定了问题的主体，那么系统的利益相关人（用现代管理学语言叫：stakeholder）就确定了下来。所发现的问题，会有几种情况：
- 某个或者某些利益相关人负载太重。
- 时间上的负载太重。
- 空间上的负载太重，本质上还是时间上的负载太重。
- 某个或者某些利益相关人的权利和义务不对等。
架构切分的原则
情况1是切分的原因，情况2是切分不合理而导致的新的问题，最终还是要回到情况1。对于情况1，本质上都是时间上的负载。因为每个人的时间是有限的，怎么在有限的时间内做出更多的事情？那么只有把时间上连续的动作，切分成时间上可以并行的动作，在空间上横向扩展。所以切分就要有几个原则：
- 必须在连续时间内发生的一个活动，不能切分。比如孕妇怀孕，必须要10月怀胎，不能够切成10个人一个月完成。
- 切分出来的部分的负责人，对这个部分的权利和义务必须是对等的。比方说妈妈10月怀胎，妈妈有权利处置小孩的出生和抚养，同样也对小孩的出生和抚养负责。为什么必须是这样呢? 因为如果权利和义务是不对等的话，会伤害每个个体的利益，分出来执行的效率会比没有分出来还要低，实际上也损害了整体的利益，这违背了提升整体利益的初衷。
- 切分出来的部分，不应该超出一个自然人的负载。当然对于每个人的能力不同，负载能力也不一样，需要不断的根据实际情况调整，这实际上就是运营。
- 切分是内部活动，内部无论怎么切，对整个系统的外部应该是透明的。如果因为切分导致整个系统解决的问题发生了变化，那么这个变化不属于架构的活动。当然很多时候当我们把问题分析的比较清楚的时候，整个系统的边界会进一步的完善，这就会形成螺旋式的进化。但这不属于架构所应该解决的问题。进化的发生，也会导致新的架构的切分。
原则2是确保我们不能违反人性，因为维护自己的利益，是每个人的本性。只有权利和义务对等才能做到这一点。从原则2的也可以推理，所有的架构分拆，都应该是形成树状的结果，不应该变成有向图，更不应该是无向图。很多人一谈架构，必谈分层，但是基本上都没意识到，是因为把一个整体分拆为了一棵树，因为有了树，才有层。
从某种意义上来说，谈架构就是谈分层，似乎也没有错，但是还是知道为什么比较好。从根节点下来，深度相同的是同一层。
当然如果某个节点的能力很强，也可以达到减小树的高度的结果。技术的提升，也是可以提升每个节点的能力，降低树的层数。
架构切分的输出实际上就是一个系统的模型，对于一个整体问题，有多少的相关方，每个相关方需要承担哪些权利和义务，不同的相关方是如何结合起来完成系统的整体任务的。有的时候是从上往下切（企业），有的时候是从下往上合并，有的时候两者皆有之（人类社会的发展）。而切分的结果最终都会体现在组织架构上，因为我们切分的实际上就是人的利益。
对架构切分，总结一下：
架构切分=利益调整，利益调整代表了以人为中心，进行的利益在分配。从时间负载、空间负载触发架构切分，而架构切分的原则就是以人的利益为本，也可以说不违背人的本性，切分的过程其实就是分层建模的过程，分层建模就是概念划分的过程，每个概念背后都代表一个问题，最终会形成树状的组织结构，而这种组织结构的调整会涉及到人的组织架构，从而要切实要考虑到人的利益。
架构其实就是在解决人的问题，如上文所述，人的问题会有很多种，比如：生活生存问题、人类延续问题、生产高效问题等等。在面对这些问题时，人逐渐主动会对自然界进行认识，从而产生最初的基本技术、男女分工、角色分工、群居等一些社会架构的形成。
然而在社会架构的形成过程中，通过概念认知、问题识别、架构切分等方式，以人的利益最大化为基础原则，进行一步步的分解、组合，达到并解决人的问题。
最终，对架构的认知，总结一下：
架构实际上就是指人们根据自己对世界的认识，为解决某个问题，主动地、有目的地去识别问题，总结得出概念，通过概念作为认识沟通的桥梁，对相关事物进行分解、合并，如：人、利益、问题、组织架构等等，解决这个问题的实践活动。