架构C01: 什么是架构？为什么做架构？架构师需要做什么？
好比我们要定义一个概念：
1. 首先定义边界和范畴，我们近似的称为系统
2. 再次根据自身认知把指定范畴划分为指定的抽象，也即组成系统的元素
3. 最后我们定义元素之前的联系和系统（整体）元素（局部）的规范和约束
架构的定义
恰如其分的软件架构
开发者无法平添智慧，随着业务的开展和复杂度的提高，开发者面临共同的难题：是解决昨日之难题，还是准备与明日一战？
所以他们只能升级自身的作战武器和作战方式以应对更大规模和更高复杂度的系统
软件架构就是软件系统的宏观设计
自组织，自架构，自下而上（类似碎行）
宏观架构，自上而下（规则与约束）
软件架构就是无形的武器，是知识和智慧的传承
软件开发的有形武器：IDE,编程语言，集成的开发环境
软件开发的无形武器：抽象思维，透过现象看本质，把对象的原始感知，转换成对目前局势与情景的简明扼要的理解，并根据自己的经验和思考，遵循事务的规律和周期指导自身行动继而达到自身事半功倍的效果
软件架构正式这样的武器，它帮助我们解决软件系统开发过程中因规模增长和复杂度增长带来的问题，帮助我们定义软件系统的整体与部分关系， 它帮助开发者按部就班的构建那些之前需要大师才能完成的系统，基于知识和实践的智慧传承，并不是要扼杀创造力，而是使开发者可应用其创造力去构建更大规模和复杂度的系统
代码大全
架构是需求明确后，为了正确的解决问题，做出的从顶层到底层的结构和约束的设计
广联达
架构，是对某项复杂事物的结构性规划。
软件架构，则是从宏观上对一套复 杂的软件系统的组成与特性的结构性规划。软件架构用来处理软件高层次结构的 设计和实施，它以精心选择的形式将若干结构元素进行装配，从而满足系统主要 功能和性能需求，并满足其他非功能性需求，如可靠性、可伸缩性、可移植性和 可用性等。
从全局、宏观的角度思考整个软件系统， 像城市规划师一样规划复杂的软件系统，并识别软件系统开发过程中的各类风险
软件架构的几大武器：分治，知识，抽象，可演化
分治
如何定义一个系统，如何定义部分与整体
解决复杂度和规模问题的有效策略，分治需要满足两个条件
1. 分割各部分足够小一边单个人就能解决他们，类似自组织和自我类似
2. 考虑如何将各部分组装为一个整体，向下打散，向上聚合，软件开发的组织方式和其他组织都有类似，都需要考虑，中心和地方，核心与局部的定义以及联系方式
这里引用一下《微服务架构设计模式》中系统的定义: 在既定的范畴内，被定义组成元素，以及元素之前的联系
被封装的部分越容易理解，将各部分组成为整体时细节就越少就越简单（元素定义），这可以帮助我们更好的推断和设计个部分之间的协作方式（元素联系）
知识
实践中的来的知识，用来指导自己更好的解决显示中的问题
最佳实践,复盘总结，数据，演讲，源代码，设计文档，白板草图......
抽象
抽象能够精简问题空间，问题越小越好理解，因而能够有效的解决复杂度及规模带来的问题
抽象其实是对系统组成元素的定义，越是简单就越是能够更好的定义各个元素的功能，就越容易定义推断和设计元素之间的协作方式，就越便捷的能够实现一个系统
现实中纷繁复杂的事物和规律 不管在生物界，动物界，其本质往往是简单的规则重复，自我组织，自我类似，就好比水分子按固定的规则排列，最后形成了漂亮的雪花，具体请研究 碎行的概念，自组织的概念
可演化
包容变化，兼容变化
http://www.uml.org.cn/zjjs/201807034.asp?artid=20908
架构设计不是静态的，而是动态演化的。只有能够不断应对环境变化的系统，才是有生命力的系统。所以即使你掌握了抽象、分层和分治这三种基本思维，仍然需要演化式思维，在设计的同时，借助反馈和进化的力量推动架构的持续演进
软件架构内部成本与收益的博弈
质量属性：可修改性，可伸缩性，延时时间
天下没有免费的午餐，提升一种就会抑制另外一种，属性之间会互相抵消的
我们拆分微服务，由中心到分布式，带来的伸缩性提高了，但是就要承受可修改性降低，延迟时间增加，这里想要表达的核心是，任何操作都是由成本的想获取某方面的提升必然要付出其他方面的代价
概念模型
所谓概念模型，可以理解为最佳实践，设计模式，等等，这些都是在特性场景下得出的关于质量属性运用的一些模板和范例，是在实践中形成的如何运用质量属性的心得体会的总结，是一种对质量属性如何运用在架构上的认知和预判
抽象与约束
抽象是元素定义，约束表述元素联系
架构由很多细小的部分组成，我们既要见微知著对某个方法进行实现，也要在系统层面对整体由一个设计，这样简单功能的部分才能和系统性的整体功能性的组合在一起
OKR 的上下约束，从上到下是约束，从下到上是对齐，整体对局部元素是有约束，局部元素到整体要有对齐，而简单则会让二者更牢固和更自然符合组织和结构的特性和定义
架构中我们设计的组件和模块是抽象，它们往往要有遵循严格的约束，实现一些列的接口继承一系列的方法，施加这些约束是为了让系统元素的联系更有预期，是系统的推导和设计更简单，使思考问题的维度更确定，更简单
软件架构师是干啥的?
《深度思考解密》王富强 老师，系统化思考章节的阐述
分与合描述的就是整体和部分，他们是一个整体，切勿之仅仅关注一个
分：静态的局部思考，抽象的帮我们聚焦的分析一个事物
分其实是为了简化事物的理解，分了之后最终是要合，融合之后就可以帮助我们理解更为复杂的事物，分不是终点，而只是起点。
所以，让自己首先学会包容和接纳不同的意见和事物, 然后再分析和了解他们，并最终融合他们吧！
合：整体的动态思考，让我们看清事物的全貌以及内外部的联系
我们要系统化思考，那么就得尽可能将不同的事物纳入到自己的思考体系中来，
连接是将不同的点和事物连接到一起形成更大层面的认知，
但是，如果纳入自己思考体系的点和事物数量不够大，得出来的思考也很大程度上是狭隘和偏颇的，所以，这就要求我们尽可能去了解更多的东西，然后纳入到自己的思考体系中来
架构师是连接器，C位
在软件行业，技术专家是专业的人，负责精深钻研某个领域的技术，而架构
师是负责连接的人，大家各自有各自的优势，需要协同合作才能创造更大的成果。这其实跟公司的 CEO 作为组织者，将各种专业的人组织到一起来完成同一个愿景是一个道理
架构师角色认知,最后借用一句话：从无到有的是架构；从表到里的是抽象；从粗到细的是设计
像架构师一样思考用价值找寻重心：先做哪些事情会比后做哪些事情更能创造收益。
像架构师那样全局性思考，把遇到问题进行抽象和分治，结合架构实践和自身认知进行自上而下的包含约束的设计
