目录
第一章 生命周期
- 非核心生命周期一旦拆分出来以后，往往就变成一个通用的服务，反而获得了更大的生命力，不再局限于原有的大的生命周期。对非核心生命周期的掌握，慢慢也就成为了一个一个的职业。
- 而原有的大生命周期则变得更加精简，可以更加专注一自己的核心生命周期活动，以节省更多的时间。
第二章 时间
第三章 为什么产生架构
第四章 什么是架构
1.架构产生的条件
- 必须要由执行的工作
- 每个人的时间有限
- 对目标要求有更高的要求
- 对目标系统的复杂性使得单个人完成是会受限于时间
- 建筑构架按照人类生命周期的需求，对地球上的空间进行切分，并通过门窗、地基等技术，保持和地球以及空间的有机沟通。
- 人类的必要生命周期活动，如吃、睡等，是和时间相关的，自然也会根据人的生命周期规律按照时间来划分内部空间。
2.什么是架构
- 根据要解决的人类的问题，对目标系统进行定界
- 围绕目标系统核心生命周期进行切分
- 对这些切分出来的部分，确定各自的生命周期及其主体，以及负责的角色
- 在这些拆分出来的非核心生命周期和核心生命周期之间建立沟通机制，使得只写核心生命周期能够围绕核心生命周期，通过树状架构组装起来成为一个整体，共同为核心生命周期做出贡献。
第五章 架构和树
第六章 概念
- 每一个概念实际上所解决的，还是人们的某个特定的问题，人们把解决问题的解决方案，给定了一个名字，这个名字就是对应的某个特定的概念。
第七章 生命是抽象
- 因为解决的问题不一样，两个概念的个性不是完全一样的，所以我们不能用抽象来定义一个事物。抽象实际上是一个分类的过程，抽取出事物中人们所关心的一些特征，并且不同的人抽取的侧重点是不一样的，甚至完全不相同。
第八章 识别困难
- 识别问题的一个最重要的前提就是要搞清楚:是谁的问题，也就是要先明确问题的主体是谁。主体搞清楚，问题的边界也就跟着确定了，再去讨论问题才有意义。
- 任何找上架构师的问题，绝对不是真正的问题。
- 架构师都要有这个自觉：发现问题永远比解决问题更加重要。
第九章 切分的原则
- 人们在人类社会生存、立足、做人的基本道德和原则:先要付出才能有收获。
- 架构切分的原则：
1.被切分的生命周期，如果必须要生命周期的主体在连续时间内持续执行，而且不能挂起被打断并更换生命周期主体的话，就不能切分出去。
2.每个生命周期的负责人，对所负责生命周期的权利和义务必须是对等的。
3.切分出来的生命周期，不该超出一个自然人的负载。
4.切分是内部活动，内部无论怎么切，对整个系统的外部都应该是透明的。
- 总结：
1.架构的切分的导火索是人的负载太重，也就是时间不够。
2.架构的切分实际上是对利益相关人的利益进行切分或合并，是的每一个利益相关人员的权责是对等的，每一个利益相关人可以为自己的利益负责。
3.架构切分是最终结果都会体现在组织架构上，只有这样才能够让架构落地并推进。
4.架构切分的结构一定是一个树状，这也是为什么会产生分层。
第十章 架构和流程
第十一章 什么是架构师
- 架构的目的是为了增长。
第十二章 什么是软件
第十三章 软件的生命周期
- 软件的整个生命周期也会发生切分，从而形成两个子生命周期：软件开发生命周期和软件运行生命周期。
- 从另一个角度来说，人们真正需要的是软件启动后为我们带来的服务，也就是说软件运行生命周期才是人们真正需要软件的地方。
- 围绕着软件的生命周期，还会切分出来很多其他的非核心生命周期：
1.软件的开发生命周期。（内部还会发生切分，如需求生命周期、代码开发生命周期、测试生命周期等）。
2.软件的运行生命周期。（a.软件的访问生命周期。b.软件的功能生命周期。c.软件的监控生命周期。）
- 从软件运行的生命周期的角度来说，一个可运行的独立部署单元才算是一个软件。
- 另一个学习的判断标准就是：学习一个东西如果只是能听懂，还不算学会；如果自己能够按照所学的执行，也才学会了一半；如果能够把自己所学的东西用自己的语言表达出来，让别人听懂，这才算才不多学会了。
- 而想对软件和计算机之外的行业业务进行模拟，软件工程师还要对改业务所在的行业的专业知识进行一定的积累，并要超越听懂和能执行两个阶段，才能用另外一种语言，也就是计算机语言表达出来。这是一个相当高的要求。
- 无论是哪种切分或分工模式，即软件开发模式，其目标都是达到软件开发的增长。
第十四章 什么是软件架构
- 生成的架构如下：
1.在软件开发生命周期中采用的人员越来越多，就会形成软件开发团队的组织架构。
a.为了让业务在软件中实现并落地，并便于用户对软件的访问，需要前端人员、业务代码人员、存储人员等不同技巧的人同时工作，并把代码进行切分，形成代码的架构。
- 从分层的角度进行思考的时候，要千万注意不要破坏树的架构。有树才会有分层，有分层却不一定有树。
b.为了完成业务的工作，需要把识别出来的业务架构和支持业务的组织架构，以及业务运作的核心生命流程，用代码表述出来。
2.在软件的运行周期中，当软件的流量越来越大时，慢慢会超出软件所在机器的能力。
离开了组织架构，任何软件架构设计都是纸上谈兵，因为软件的核心生命周期就是架构的执行。
第十五章 什么是软件架构师
- 具备架构师头衔的人并不一定是架构师。
- 架构师的核心在于架构的执行，软件架构师必须是一个组织的领导人，有权利调动这个组织的架构，才能更好地发挥架构师的作用，才能够把软件开发生命周期、软件运行生命周期和业务生命周期的拆分落实执行。
- 软件开发团队的组织领导人其实就是架构师，只是没有这个头衔而已，真正的架构师并不一定具备架构师的头衔。
- 人类架构的核心就是组织架构，正确的组织架构才能保证架构的执行。
- 要想做好架构师的工作，就要向大自然学习，这样才能够认识到事务自身的生命周期，并能够去顺应事务自身的生命周期的规律来进行拆分，以达到增长的目的。
- 如果把业务认为是硬币，则可以认为架构和技术是硬币的两面，架构和技术共同组成了业务。
第十六章 业务 、架构和技术三者的关系
- 什么是技术？
通过人为创造条件，让指定的规律按照人类的意愿发生，这就是技术。
- 什么是业务？
所谓业务，就是要解决人类的问题，目的是支撑人类自身的生命周期，使人类获得利益。
- 业务是核心，技术是解决业务问题的工具，而框架是让业务长大的组织方法。
- 架构需要用技术来实现拆分，而技术需要架构来合理组织，提升效率。
- 修炼的过程就是自己的思维观念变成和作者一致的过程。
- 要想付出才能有收获，这是这个世界运行的准则。
第十七章 软件研发
- 编写软件是从科学计算中拆分出来的，变成一个通用服务，成为一个独立的职业，具有独立的生命周期。
- 这就是软件这个新技术的出现，导致了新的社会分工和新的架构拆分。
- 软件和业务最终还是要合体的。
- 软件架构师并不一定是具备架构师头衔的那位，但一定是软件研发团队组织的领导。
- 软件开发业务本身也是软件的一个业务。
- 组织软件工程师进行有效的分工，形成软件开发团队的组织架构。
- 为了减轻软件工程师的负担，要把软件开发过程中的非核心生命周期拆分出来，形成软件开发本省的业务架构，并通过自动化来提升软件工。
- 架构师本身也是架构师的一个业务，也需要架构拆分，形成不同领域的架构师。
- 软件工程师负责建设，软件架构师负责组织。
第十八章 软件的架构拆分
- 软件开发团队拆分：
一个业务团队对应一个软件开发团队，这种方式会让软件开发团队的组织也形成一棵组织树，并且这棵树和业务团队的组织树是匹配的。
- 软件拆分：
一个软件开发团开发一个软件。组织形成的还是一棵树。软件和软件之间的关系，反映的就是组织和组织之间的关系，一一对应，还是一棵树。
- 从软件团队到人，从人到组件，形成的还是一棵树。软件和组件，组件和组件之间，形成的也是一棵树。
- 重用访问通道的结果，既损伤用户的利益，也损伤软件的利益，还会损伤软件开发团队和企业的利益。
第十九章 如何写好代码
- 内聚就是确保一个事物的生命周期是完整的，而不是分裂的。所谓完整，就是指一个生命周期的主体，从生到死之间的整个过程，所发生的行为和状态是积累在一个主体上的。
- 直接把某些业务生命周期的代码拆分到另外的一个软件中，并把相应的服务代码、管理者代码和存储代码一起拆分过去。这个拆分方式就形成了新的软件，而对于原软件的影响仅仅是对被拆除过去的业务调用方式发生了变化而已，从本地调用变成了服务调用。
第二十章 单元测试
- 只要出现了模拟，单元测试就开始失败了。
- 通过别人的反馈保持的兴趣会比较短，因为很多时候别人的反馈其实处于礼貌。而自己对自己所做事情的反馈，才是至关重要的，知识形成兴趣的最终的因素。
第二十一章 软件架构和面向对象
- 面向过程反映的是生命周期按时间推进的特质，而面向对象反映的则是事务生命周期活动内聚的特质。
- 大部分时候，业务的变化都是流程的变化，并且都是和用户打交道的的部分，也就是用户访问生命周期没所以这一部分的变动最频繁。
- 业务对象是很稳定的，因为分工的变化并不是经常发生，其内在逻辑是相对稳定的，值得依赖。
- 组合实际上已经包含了面向过程和面向对象的两个特质，因为组合要使用拆分的对象来完成过程的实现。
第二十二章 软件架构与设计模式
- 软件设计模式本身是一个架构拆分的结果，只是这个才分被标准化了，所以被重复使用而已。而设计模式在被使用的时候，则不需要进行设计，直接使用即可。因此设计模式就成为了一个成熟的技巧或者技术了。
- 软件设计模式这部分的代码其实是有自己的业务领域的，这个领域就是软件的访问生命周期。
- 毕竟模式知识关注到了共性，共性只会让解决问题变得更容易、更轻松，因为别人解决过了，有参考，但无法解决真正的问题。而真正要解决问题则是要发现问题的个性，发现了个性，共性才能发挥更大的作用。
第二十三章 软件架构和软件框架、
第二十四章 软件运维
- 因为软件本身也是软件的业务。
- 运维的业务目标是保证用户的访问生命周期不受影响。
- 非核心生命周期的意思并非说该生命周期不重要，而是不再需要自己亲自干，可以分工出去给别人干，用来提高并行度。
- 每次变化的风险控制是最重要的任务。
- 而为了要控制变化，隔离环境是第一件要做的事情。
- 环境隔离导致了架构的拆分，企业的环境隔离形成了一个架构拆分。
- 监控的目的实际上就是把系统内不同生命周期的当前运行状态，通过探测器传输过来，展示到可视或可感知的设备上，来供人查看。
- 监控非常重要的指标就是实时度。
- 不留恋过去，是大自然能够得以不断持续向去发展的前提。
- 监控室生成预警的数据基础。对业务生命周期的理解则是生成预警的规则基础。
- 预警软件本身也是需要监控和预警的，也是预警的业务。
- 在生产系统做变更，也需要有一个正向的反馈环，这个正向反馈环核心环节就是监控和预警。
- 变更在生产环境的执行一般称之为发布，对变更进行管理的系统佳作发布系统。
- 生产故障时要优先恢复用户的正常访问，而不是在生产环境探查问题的根本原因。
第二十五章 软件访问生命周期
- 可以得出结论，访问路径上的业务，都是计算机和软件自身的业务，是为降低软件的开发难度而沿着访问生命周期做架构拆分而形成的。
- 计算机和软件的业务都可以归结为访问通道型的业务。
第二十六章 软件架构和大数据
第二十七章 软件架构和建筑架构
第二十八章 交易
- 交易就是人各自拿自己多余的物品，从其他人手上换取自己必须的物品，从而双方都获得利益的过程。
- 交易的背后实际上是人们相互之间的时间交换，而不是货币。货币只是对时间的定价，方便交易的一个工具。
- 对于不同的商业模式，交易都有自己的形态，需要识别出来。
第二十九上 产品
- 产品本身就是最好的营销。
- 产品系统实际上就是市场营销的起点，也是交易的起点，也是企业用来年实现自己愿景的工具，是愿景的具体化。
第三十章 用户
第三十一张 订单
- 其实浮渣的事情一开始都是简单的，简单的系统逐渐地发生拆分就变得越来越复杂了。
第三十二章 交易系统
- 业务模型完全就是现实社会中已存在的分工，建模的人只需要识别出来就可以，不需要绞尽脑汁用不同的技术抽象出来另外建立一个模型来表达业务。
- 访问通道的另一个非常重要的要求是，不同类型的用户访问要提供单独的访问通道。
- 要让各方都有自己的访问通道，保证访问通道不能够重用。
- 不重用访问通达的目的是为了重用业务对象。一旦重用访问通道，业务对象中的业务逻辑一定会分散到访问通道中，业务逻辑反而得不到重用了。
- 一旦软件发生了架构拆分，原来的本地调用就变成了服务调用。
- 架构拆分导致了服务的出现，反过来，服务也是达到加厚拆分的必要技术手段。
- 服务有自己独立的生命周期，会形成自己独立的业务，不再依赖于原核心生命周期，焕发出型的活力。
第三十三章 事务