版权声明：本文为博主原创文章，未经博主允许不得转载。 https://blog.csdn.net/crowhyc/article/details/72729509
1.认识架构
1.1生命周期：
- 万物皆有生命周期
- 生命周期包含各种活动，活动的推进是生命周期的必要因素（对象的行为）
- 生命周期里面的活动拆分后，形成若干新的生命周期
- 拆分后主体不变的是核心生命周期，变化了的是非核心生命周期
- 每个主体的生命周期变化都累积在自身，这个就是所谓的内聚（面向对象分析新思路）
- 生命周期拆分以后，因为非核心生命周期的主体已经发生变化。主体便可以将这些非核心生命周期分配给其他主体代为执行。这样，生命周期从时间连续的执行变成了空间上并行，时间上串行的连续活动。
- 新的技术诞生也会导致某些核心生命周期变为非核心生命周期，例如照相机的发明导致了人看到物体的生命周期发生了主体转变。
核心生命周期在拆分后，变成了通用服务，最后演变成了一个个职业。而大生命周期变得更加精简，可以更加专注自己核心生命周期
1.2时间：
- 时间是人们对事物变化的一种度量
- 万物遵循生命周期规律，随时间流逝生生灭灭，不因个人意志所转移。
生命无常，虽然每个人个体的生命周期无法按自我意愿进行延长。但是，通过提高自身的能力以获得更多成就，产生对社会更多的贡献，这是另一种层面的生命的延伸
1.3为什么产生架构：
- 推动人类社会架构的产生，本质上是人类对于时间无法控制的恐惧。
- 按特点进行分工以后，生产力得到了提升。相对的人的生命得到了一定的延长。
- 实际上按特长进行分工便形成了人类社会的架构。
- 良好的社会架构和分工使独立的人类节约了为了生存付出的时间。有了更多的精力来干自己有意愿去做的事，或更加擅长的工作。
让擅长的人去做他擅长的事，每个人可以专注于自身擅长的事和喜爱的事。
1.4什么是架构：
- 架构的思考来源于对生命周期的识别，以及对生命周期的拆分。
- 如何定义架构：
a) 根据要解决的问题，确定问题的主题，界定目标的边界。
b) 切分目标的生命周期，区别核心与非核心生命周期。将非核心生命周期独立起来，使之并行起来，缩短整个生命周期的执行时间。
c) 对切分后的部分，确定各自的生命周期和主体，以及负责的角色。
d）在拆分后的生命周期之间建立沟通机制。让非核心生命周期可以围绕核心生命周期形成树状结构，提供其需要的服务。 - 架构总是在业务遇到瓶颈过程中产生，在瓶颈的解决中应用，在业务消亡时一起消亡
- 自然业务的生命周期就是架构的生命周期
- 每种业务架构拆分是确定的，区别的只是规模不同
架构是为了业务而服务，让业务更加高效，让业务更健壮，让业务更服务于更多的人
1.5架构和树
- 树状结构的增长成本低，沟通路径增长少，沟通和能量传递行好。架构的产生恰恰是为了应对增长，自然而然架构都是树状架构的。
- 树状结构主次分离，非核心生命周期发生问题不会造成系统性问题。
- 非树状的分离不算架构，因为非树状结构无法保证架构的权责分离，业务会阻碍增长。
- 架构的目的是让树按自己的规律成长，而不是反过来在业务中加入架构自己的材料，干扰核心业务。
- 树状结构的权责对等不保证了参与人能从自身工作中获利，从而保证参与人能够持续的推进业务的生命周期。
树状结构是架构的必要结构，脱离树状结构架构的设计不能应对业务的持续增长
1.6概念
- 概念是人互相沟通并认识这个世界的基础
- 不同的概念是为了解决不同的问题而产生的。客观环境决定了概念解决的具体问题。（同一个概念名词在不同的客观环境下解决的很有可能不是同一个问题）
- 设计架构时，先去探索概念所解决的问题，才能更加准确的区分核心、非核心生命周期，为架构打好基础（需求分析的方法论）
人与人之间沟通的基础是概念，但是每个人在不同的客观环境中所成长，所以在对架构的分析和设计中需要先统一概念，才能真正的设计出符合业务的架构
1.7什么是抽象
- 抽象实际上是把很多不同概念的相似部分合并在一起，形成一个新的概念。
- 抽象是一个分类的过程，根据不同的人或业务抽取出所关心的特征。
- 架构设计者必须要置身业务中，感受业务的个性，认识到业务所面临的问题。在充分了解个性的基础上才能谈到共性，否则这个抽象只是个人臆想的假共性。
共性和个性因不同人和业务方向而不同，在抽象共性的时候充分理解个性才能更好的抽象共性，从而设计出更加适合的架构
1.8识别问题
- 核心生命周期才是最主要需要解决的问题
- 识别问题的能力决定着架构师的水平
- 解决问题要克服对时间的焦虑，要先耐心的把问题搞清楚
- 搞清问题先要了解问题是谁提出的，搞清真正的问题是什么样的。
- 不分析清楚问题就去解决问题，最后结果是问题没有被解决。反而，还产生了新的问题需要去解决。
强势插入：有时候产品或者需求方直接给出的是问题解决方案。但是，大部分情况下这个解决方案并不能真正的解决他们需要解决的问题。所以就导致了需求重复变更，开发人员不断抱怨，结果问题还没解决。开发人员应该尽可能的通过沟通和交流了解需求方的真正问题。 - 工程师在解决问题的时候应该好好思考，到底是在帮谁解决问题。搞清楚提出问题的主体才能找到真正的解决方案。（抱着完成自己工作任务的思想，去处理问题的方式是非常危险的。因为此时问题主体已经变成了“我”，而不是真正需要解决问题的主体）
- 任何找到架构师的问题，都不是真正的问题。
- 发现问题永远都比解决问题更重要。
- 警惕那些直接提出解决方案的问题，基本上这类解决方案都不能解决真正的问题。 *
a)这是谁的问题?
b)什么问题?
1.9切分的原则
- 所有的切分调整，都是对相关人的利益进行调整。（人个体对利益最大化的追求）
- 在社会上，提供的服务更多更好，就能换取到更多更好的生活必需品。
- 利益才是原动力（引申：相干人培训–王直）
- 切分不均衡导致的权责不均衡会导致生命周期无法顺利进行
- 切分出来的生命周期不能超过一个自然人的负载（自然人的负载也根据个体不同而不同）
- 切分是内部行为，应该对系统外是透明的（边界区分）
- 架构的前提是吧一个生命周期连续过程拆分成了一棵树，因为有了树才会有层的出现。
- 树的层次越低，沟通损失越小，效率越高。（管理扁平化）
- 节点能力提升或技术提升都可以帮助减少其子树的深度。
- 切分的结果最后会体现在组织架构上。
良好的切分会让整个业务架构树茁壮成长，子节点的权责不对等则会导致整个架构受影响
1.10架构与流程
- 流程就是多个角色为了把一件事做好，按时间顺序协作并完成的整个过程。
- 流程形式上与生命周期相似，但流程关注的并非生灭，而且多个人如何完成同一个目标。
- 流程是描述整个事物发展各种可能性的树
业务为了长大发生了架构拆分，形成了树。而流程把拆分之后的业务进行组合，通过遍历树，重新形成了业务生命周期整体
1.11什么是架构师
- 架构师要发现问题的主体，挖掘出核心生命周期。合理分配非核心生命周期的职责。根据核心生命周期将工作成功组合起来，达到1+1>2的效果
- 架构师的权责也要是对等的。
- 架构师的工作效果应该由解决问题的效果也就是增长的效果来决定
- 架构师应该是某个业务或领域的负责人，如果置身于业务子节点中，架构的分配方案将难以落地
人人都是架构师。在生活当中每个人或多或少的都在进行着业务的架构划分。比如，桌面的摆放，软件的顺序，到达某个点的路线。在阅读本书的过程后，从雾里看花，身在此山中的感觉中走了出来。发现架构无处不在，不管是夫妻之间，同事之间，朋友之间。根据不同的主体进行分析，了解他的主要问题所在，或者沟通的要点。将会给生活、工作带来莫大的帮助