有感于自己对架构似是而非、朦朦胧胧的理解，并且对于架构的基础理论没有形成知识体系，所以就想从一些优秀的开源框架中去学习它们的设计思想，同时基于自己的理解和积累看能否总结出属于自己的架构知识体系。
我不知道自己能写出一些什么东西，也不知道自己能坚持多久，但是平时教导儿子什么都要勇于尝试，身为父亲更应当以身做则，于是乎就写下了这篇，后续会输出一些我个人阅读源码时的一些理解。
输出的目的其实很简单：我希望我能把我理解的东西清晰的描述出来。以此来检验我是否真的理解了。
这篇文章是这个系列的开篇（努力让系列成为可能），主要包括以下内容：
- 对架构师的灵魂拷问
- 架构是不是无迹可寻
- 让架构成为重中之重
以下是正文开始，文中所参考的链接全部放在文末。
0x01 对架构师的灵魂拷问
“什么是软件架构？”
我觉得这个问题可以成为IT行业的灵魂拷问。为什么呢？我个人的感受是：因为似乎100个人对架构（以下特指软件架构）这个词会出现100种理解，然而更奇妙的地方在于，对于不同的人所理解的架构的含义，基本上你无法指出对方的理解哪里不对，同时，又会觉得好像和自己的理解不完全一样，而且你还不一定能给别人解释清楚。
我自己对架构的定义理解就是这样一种状态。
当我发现自己无法对架构这个词给出清晰的描述时，我就去搜索引擎搜索，于是在维基百科上找到了关于它的定义：
软件架构是有关软件整体结构与组件的抽象描述，用于指导大型软件系统各个方面的设计。
看完这句话并没有帮助我理解软件架构的定义。中文版看不懂，那就切到英文版。
Software architecture refers to the fundamental structures of a software system and the discipline of creating such structures and systems. Each structure comprises software elements, relations among them, and properties of both elements and relations. The architecture of a software system is a metaphor, analogous to the architecture of a building. It functions as a blueprint for the system and the developing project, laying out the tasks necessary to be executed by the design teams.
Software architecture is about making fundamental structural choices that are costly to change once implemented. Software architecture choices include specific structural options from possibilities in the design of the software.
大意就是说软件架构是软件系统的基石，它是对建筑学中建筑架构的一种类比，它是系统和项目开发的蓝图，指明了设计团队必须要实现的任务。并且软件架构是对（系统的）基础结构做选择的，这个选择一旦被实现之后，再要修改将会耗费巨大的成本。软件架构的选择包括了在软件设计时所有明确的结构选项。
感觉也还不是那么的清楚，完全不像我们平时所碰到的对名词的定义。
在继续搜索的过程中，找到了大师（Martin Fowler）的一篇文章（Software Architecture Guide），里面的第一个问题就是我们最前面的灵魂拷问：
What is architecture?
大师Martin Fowler说在软件界，人们对架构的定义已经争论了很久（long argued），他和另外一名大师（Ralph Johnson，Gang of Four Design Patterns的作者之一）通过邮件的不断交流，得出的一个想法是：从一个更好的角度来看，架构是用来分享开发专家对系统设计的理解的（英文原文： a better view of architecture was the shared understanding that the expert developers have of the system design.）。
而大师Ralph Johnson的结论是：不管它是什么，反正架构是很重要的东西。（英文原文：Architecture is about the important stuff. Whatever that is.）
看来业内大师们也没能给架构给出一个明确的定义（所以在文章开头我把这个问题当作是灵魂拷问），那我自己的这种朦胧状态的理解应该也没有什么问题了。
0x02 架构是不是无迹可寻
虽然没有人对架构给出过明确的定义，那架构是不是无迹可寻呢？
答案是：架构是有迹可寻的。
大师Martin Fowler前面的结论可以看作是架构的一种意义（不是含义，也不是定义）吧：架构是用来分享开发专家对系统设计的理解的。
既然架构是用来分享设计者的理念的，那我们是不是可以理解为：开发专家（架构师）针对系统的需求，作出了自己的设计（或是团队做出的设计），并给出了实现。那假如有一天，有别人（或别的团队）需要用到这个实现，对方希望能够理解该实现的设计原理和思想，以及如何通过扩展与自己的设计实现进行集成，这时怎么办呢？当然是让对方理解自己的设计思想了，明白了设计思想就能理解实现中的各个模块、组件的用途和意义了，同时也理解了整个设计是如何组成一个整体，如何运作的了。
那分享的对象只有同样角色的开发人员或开发团队吗？
答案是：不一定。
分享的对象有可能是具体的开发人员，也有可能是用户（使用者），还有可能是需求方的管理者等等。
既然分享的目标群体多样，那是不是就应该针对不同的目标群体有不同的分享内容呢？毕竟你把软件设计的思想（例如：系统使用了哪些设计模式，组件拆分的考虑是基于什么考虑等）分享给用户，用户也未必能懂，最关键的点在于用户所关注的点并不在你的系统设计上，而是在系统的使用上。对需求方的管理层这个目标群体，道理也一样。
所以，这里就需要有针对不同相关方的架构文档存在了。针对不同相关方的架构文档的具体内容有重叠也有不同，比如，针对开发人员的架构文档应该更关注系统设计的细节，类似于组件之间的调用流程、时序等；针对需求方管理层的架构文档更关注系统的部署模型等。
具体到架构设计过程中，可以对应到不同的架构视图，不同的目标群体对应到的不同的架构视图的组合不同。
到这里就和我们平常在到处看到的关于架构的视图、架构方法这些理论和实践关联起来了。
以上是软件架构的架构图（出自李智慧老师）
0x03 让架构成为重中之重
大师Martin Fowler在OSCON 2015的演讲Making Architecture Matter中提出了一个概念：设计耐力假说（Design Stamina Hypothesis），大师指出要重视内部质量（internal quality，内部质量就是指用户所看不到的系统部分），具体的原因他写在了他的另一篇文章中了。
我个人对Design Stamina Hypothesis的理解觉得应该更像是可持续化的设计，因为设计本身自始至终就不会是一成不变的，设计应该随着需求的不断变化而作出相应的调整（也就是通常所说的重构），换句话说：每次上线时，系统的架构设计应当是符合当前需求所作出的最适合的设计。不断的保证这一点才能保证大师所说的good design，也才能更好的配合CI/CD，快速迭代。
0x04 结尾
以上是我个人查阅资源后，对什么是架构，以及为什么要有不同的架构视图，为什么是这几种视图这些问题的理解。
这一篇似乎和读源码没什么关系，确实是的，但是我读源码的目的是想从一些优秀的框架中学习它们的架构设计思想的，所以有必要先理解到底什么是构架。