什么是架构？
Ralph Johnson 说架构是 『Architecture is about the important stuff. Whatever that is.』，中文的意思就是『重要的东西』，架构师的工作就是理解权衡『重要的东西』。理解，即理解业务需求；权衡，即取舍之道。这点正如，企业初创通常我们都是『单体应用』来快速构建，快速的推进业务，而随着业务发展，我们只能根据业务形态来不断的改进架构。以时间的维度思考架构的连续性变化，即是演进式架构。
物种的演进方式大致有两种：一种是渐进式，一种是爆发式。对于架构的演进同样如此，在此我们不区分渐进还是爆发，关注点是原始架构到渐进或爆发后的架构演进能力。（某些爆发式突变应该不在演进支撑的范畴）
我们的人生是取舍，架构何尝不是取舍。而取舍的关键是，重要度的排序，我们必然选择最重要的来做，而忽略不重要的。人生要做当下最重要的事，公司要做价值最大的事，架构也是要解决最大的业务问题。
架构为什么不是一成不变的？其实很好解释，从生死的角度来看，一个事物有诞生就会有死亡，架构这个人为的事物也是如此，诞生就一定有死亡，不想死掉，所以要演进。即在时间维度下，架构的比特衰减在所难免。
架构划分的维度可以多种多样，按照技术、数据、安全、运维划分是一种方式；按照不同视图划分：逻辑视图、开发视图、进程视图和物理视图；也可以单独针对具体需求设计性能、安全、合法性、伸缩性等维度划分。无论那个维度，都需要考虑时间的维度叠加的考量。演进式架构中的三个重要元素则为 “增量式变更”，“适应度函数” 以及 “适当的耦合”。
架构不是单纯的软件需求任务也要考虑人员的组成来进行思考，因为『康威定律』写到『Organizations which design systems … are constrained to produce designs which are copies of the communication structures of these organizations.』，即『设计系统的架构受制于产生这些设计的组织的沟通结构。』所以软件架构必须考虑落地的人的组织形式，这里会引入两点思考：
一、软件架构要考虑现有的团队划分，能够适应现在的团队组织形式；
二、软件架构考虑打破现有的架构，在软件架构层面设计，并考虑落地的人员组织形式。可以看出后者明显优于前者，当然在能力有限时，只能做前者的选择，而且要把组织结构看做需求的限制条件之一。
在我眼里架构师其实做的事情就是『庖丁解牛』过程，『牛』是指遇到的需求，『解牛』则是对需求的拆解，其过程必然要『依乎天理』，什么是天理，天理就是『道也，进乎技矣』，就是合理的拆分形成技术架构。怎么算合理呢？『实践是检验真理的唯一标准』。不同的需求就会有不同的『牛』、『虎』、『蛇』....，这就需要不同的『解法』。再说的直白一点，把需求的结果看做是个假想的系统，架构就是把系统进行合理的（即合道）分拆，可以是子系统、模块、组件、构件等等。"系统绝不是其组成部分的总和，而是各部分相互作用的产物。"
架构的考量
适应度函数：针对架构特征进行客观评估的能力。即你说『高可用』，验证『高可用』的可靠方式或方法。
增量变更：针对架构的变更，能够快速的在原有基础上进行变更，设置能够并行。例如：功能向前兼容，多版本支持；DevOps的落地，蓝绿部署，金丝雀部署、feature toggles等。
适当的耦合：是指模块建会存在一定的耦合。例如都使用了同样的工具、框架、库等等。
架构量子：系统最小的可部署单元（代码+数据...）。架构量子越小，架构的演进能力越强，例如FaaS
一些摘要：
假设驱动开发的假设是根据假设来检验的，什么试验可以确定结果以及用什么验证假设意味着应用开发的走向。
演进的速度和生产周期成正比，生产周期越短，演进越快。
积极地更新框架依赖，消极地更新库。
要选择出高效的架构，他们必须仔细了解对应的问题域并选择最合适的架构，这样才能提供最理想的能力并且破坏性约束最小。当然，除非架构师陷入了简历驱动开发的陷阱——为了用这些知识丰富自己的简历而选择框架和库
事不过三，三则重构：第一次做某件事时，你尽管去做。第二次做类似的事时，你会对重复犹豫，但无论如何你还是重复这件事。第三次再处理类似的事时，你应该将其重构
参考：
https://www.thoughtworks.com/insights/blog/microservices-evolutionary-architecture
https://gist.github.com/scottwd9/ada88f963aac95893e1eba10d4ad8f6d
