《聊聊架构》笔记记录
姬凡
第一章： 生命周期
我们常说的内聚这个概念，当我们找到了核心的生命周期后（拆分之后主体不变的子生命周期），核心的主体是不会变化的，也就是
核心业务的确定，这个东西是很难的变化的，而其他的非核心业务都是围绕这个来走的。这是一个大的方向的内聚，如果说小的方向的内聚
就是我们的每一个生命周期的确定， 核心往往都是在一个类里面定义生命周期的开始和结束的，这样的话， 其他的业务都是围绕这个方向来的，
所有的控制也就都聚集在一个或者多个类中，这样的话，其他的类调用的方法的时候，开始业务的时候，都是通过这个类来调用的，这样的话，内聚的模式
也就实现。
核心业务和非核心业务的产生可以并行的，这样的话，我们就可以进行模块化编程了，
在理解非核心业务的时候，可以发现，真正核心的业务，往往都是不可以复制的，也就是说他都有各自的特性。所以，这样一对比的话，非核心业务可以就是一个通用的方案， 不仅可以提供给自己的这个模块用，也许其他的模块也是可以用的。就是一个通用的服务了。这样的话，通用的模块化编程也就出来了。同时这一块的生命力也就更强大了。
第四章： 什么是架构
架构的切分原则就是让非核心生命周期独立出来，便于不同的角色并行的开展工作。首先要在空间上进行拆分，使得空间上的管理可以并行，而时间上进行串行。
每一个切分出来的生命周期应该都是完整的，也就是一个独立的模块，模块都是相互独立和相互关联的。这些模块的活动的结果都在改生命周期的主体上进行累积，这也就是内聚。
拆分出来的非核心生命周期应该都是围绕核心生命周期，这样的一个树状结构，也就是一个横向的发展来进行和主体生命的沟通。这样的沟通效率比较的高。
同时要明白，架构的拆分就是对业务模块的拆分，软件的架构就是模拟业务的一个活动，更准确的说就是模拟人的一个活动的过程。
拆分的原则就是把非核心生命周期拆分出来，有不同的角色来负责，让人们可以并行的工作，每一个角色达到权责对等，并形成不同角色各自的激励机制，
非核心业务的增长都是付出贡献给核心业务，这样核心业务收益的同时自己也收益。
第八章：识别问题
找出问题的主体， 是做架构的首要问题。
第九章：切分的原则
因为维护自己的利益，是每个人的本性，每个人都逃避不了这一点。
每次政权的更迭，都是由不同的群体的利益重新分配的动力所推动并决定的。
没人愿意去损坏自己的利益，一旦去强制执行，人心就容易涣散。
第十四章：什么是软件架构
业务问题的本质就是业务所服务对象的利益问题。
通过对业务生命周期的拆分，突出并精简业务核心生命周期，拆分出非核心生命周期，达到不同的生命周期在空间和时间上并行，便于不同的人同时开展工作，
提升业务人员的单位时间内的产出。
第十五章：什么是软件架构师
软件的核心就是模拟人类的业务，而不再软件的本身。
架构师思考技术时更多的考虑技术对生命周期拆分的支撑，以及不同技术实现拆分时落地的成本和收益。
技术人员要想成为架构师，必须跳出技术的视角，换一个角度去看技术，要把时间花在研究生命周期规律和业务的增长上，花在选择合适的技术上，而不是只是追求新潮的或资金喜欢的技术。
第十六章：业务，架构和技术三者的关系
软件是模仿人类的。
业务是核心，技术时解决业务问题的工具，而架构师让业务长大的组织的方法。
第十八章： 软件的架构拆分
架构拆分的原则首先来源于业务自身的组织架构，使得软件架构保持和业务组织架构的匹配关系，其次来源于软件开发团队自身的组织架构，最后来源于用户的流量对软件本身的冲击。
第十九章： 如何写好代码
内聚，是指某个生命周期的变化是累积在一个生命周期的主体上，而不是分散在不同的主体上。
从生到死之间的整个过程中，所发生的行为和状态是累积在一个主体上的。
注意：不能把业务模型当做数据对象来处理。
业务模型关心的是其生命周期，数据是这些生命周期行为的状态，所以黏合代码需要把业务模型转换为存储设备的实体（Entity），实体和存储设备里面的存储粒度一一对应 跟随着表的变化而去变化，这样就保证了存储设备的变更不会影响业务模型。同业业务模型不能拿来用作服务和用户之间的数据交互媒介，只能转成DTO，也就是说业务模型对用户是不可见的。这样用户的需要的展示的数据的变化并不会影响业务模型。同时这一块也是变化的最频繁的，这样的话DTO就是很好的解决了这个问题了。
业务模型总是围绕着核心生命周期展开的一个树状架构。
第二十章： 单元测试
单元测试代码保证代码的健壮性， 减少代码的BUG数。
第二十一章： 软件架构和面向对象
不同的代码人员也可以也分别关注同的生命周期（前提是对象已经封装处理），并行的编写代码，从而提升代码产出的效率，使得不同的代码人员之间不会互相干扰，这就是“内聚”产生的“松耦合”。
第二十二章： 软件架构与设计模式
设计可以理解为一种有计划，有目的的活动。
人们创造一个事物的过程总是先建设好事物的本身，在考虑如何更好地把业务和用户连接起来。设计模式正好契合了连接用户和业务的这个需要。
所有设计模式内部的分工其实是在模拟现实生活的分工；并且设计模式内部的分工往往更加的抽象，
模式只是关注到了共性，共性只会让 解决问题变得更容易，更轻松，但是每个软件的开发都是有自己的个性，这个个性也就是自己的独特的业务能力。
第二十三章： 软件架构和软件框架
框架基本上都是根据业务模型，设计模型，把模型中稳定的部分进行封装，形成一个大的边界，但是具体的内容留有自定义化。
第二十四章： 软件运维
问题： 监控， 自动化， 集成测试。 session如何共享。 分布式事物。
架构的认识：
我们把更多的时间来处理核心的业务，这样的话，提升生命周期的质量，从而使生命得到某种程度的延长，其实这也是人类社会的架构，和人类的进步。
架构的目的并非产生一个新的业务之外的新的东西出来，只是为了让业务长得更加的高达强壮，服务更多的人，
软件是对人的模拟， 而建模实际上就是把人虚拟化， 把各业务系统负责人的工作用模型表达出来。模型中的每一个对象， 代表的就是现实生活中一个个活生生的人。
这个对象的方法， 代表的就是这个人所负责的业务生命周期的行为。
类似资料：