https://book.douban.com/people/fleure/annotation/27034443/
很多人把 MVC 中的模型（Model）理解为业务模型，这是有问题的。模型更多的是指对视图（View）的数据支持，一般用DTO来表达。而业务模型关注的是业务生命周期及其行为，业务模型的内部数据只是这些行为的结果。MVC 中的模型和业务模型是两个不同的概念，不可混用。
运维的业务目标是保证用户的访问生命周期不受影响。
非核心生命周期的意思并非说该生命周期不重要，而是不再需要自己亲自干，可以分工出去让别人干，用来提升并行度。
运维的生命周期是从软件部署开始的。
而为了要控制变化，隔离环境是第一件要做的事情。
所有生产环境的变更可以分为两类：一种是被动发生的变更，一种是企业内部主动发起的变更。… 主动变更所导致的软件系统问题大约占所有线上问题的 2/3 以上。
生成预警的主要困难在于对业务生命周期的理解。
主导变更的策略主要就是让变更逐步地发生，一般被称为“灰度发布”。
还有一个更先进的做法就是把代码发布和功能启用进行架构拆分，先确保代码上线没有问题，再通过软件开关来打开关闭某个功能，功能的打开和关闭就形成了一个新的发布生命周期。
还有一个误区是架构师和软件工程师普遍存在的一个省力思维，总想用一个不变的方法来解决所有的问题，什么代码都考虑重用。设计模式强调的也是重用，恰好满足了这一需要，因此存在滥用的状况。但是重用并不总是带来好处，比如不同角色重用同一个服务（Service），就会导致两个角色不必要的相互干扰，反而增加了新的问题。重用并不是软件开发的目标，软件开发的真正目标是模拟业务，并提供用户访问。
很多架构师或软件工程师使用了很多设计模式，就是为了让访问代码部分能够做到重用。究其根本原因，是因为这部分代码里面混入了业务逻辑，并且深深地认为这样做是对的，因为只能这么干，并且所有人都这么干。结果当业务需求快速变化的时候，设计模式因为无法规避不同用户修改需求带来的相互影响，反而导致部分的代码修改更加的困难。
在解决同一个业务问题的前提下，更高效、更低成本的技术，会淘汰低效、高成本的技术。
通常开始解决核心业务问题的核心技术（钻木取火）的效率是比较低的，只是把不可能变成了可能。从这一点上来说，技术才是业务的使能者（Enabler）。慢慢就会有提高效率的需求出现，改进技术的要求就会变得很迫切。技术所解决的业务生命周期慢慢就会开始发生拆分。非核心生命周期分离出去之后，要么使用现有的技术来实现，要么形成新的技术，服务于更广泛的业务。
业务是核心，技术是解决业务问题的工具，而架构是让业务长大的组织方法。架构需要用技术来实现拆分，而技术需要架构来合理组织，以提升效率。
当软件工程师需要帮助别人解决问题，并且按时、按需解决业务问题已经成为他们自己的问题的时候，软件工程师就有了时间的压力，潜意识里会自然而然地产生对时间的恐惧。… 为什么软件工程师会对时间有恐惧和压力呢？其原因是他们把按时完成自己的工作当成了自己的最大利益。
在软件行业，很多公司设了软件架构师的职位，主要职责是做出架构设计，也具备一定的影响力，但并不具备调动组织架构的权力。这样的职位往往达不到架构师的效果，有时候还会起反作用。因为架构师只能够通过建立某些流程来行使架构师的权力，比如强制架构 Review，给出架构建议等。时间一长反而会造成很多不必要的内部冲突，最终会导致沟通成本增加，减慢研发的速度，同时也会使这些流程流于形式，大家敷衍了事，反而增加了研发成本，得不偿失。比如有些团队为了应付架构 review，会做两套架构，一套用于 review，一套用于实施。
架构师拆分生命周期，技术人员实现生命周期。… 架构师思考技术时则更多地考虑技术对生命周期拆分的支撑，以及不同技术实现拆分时落地的成本和收益。
业务相当于基因，而架构树状拆分则相当于细胞的分裂。…基因决定了细胞最终会分裂生长成什么样的一个生命。.. 长成什么树是由基因决定的，不是架构。
所以严格来说，只有业务才会进化。架构是支撑业务长大的，形成的是新的拆分。… 如果该结构的拆分不是以增长为目的，则很难认为是架构，自然也无法称之为架构的演化，或许可以称之为结构的演化。
随着社会的发展，产生了人类的分工，分工背后的动力来自于每个人寻求自己的利益最大化的冲动。人们都希望能够在最短的时间内，得到更大的产出，把自己的利益最大化。所谓的利益，其实就是保障自身的生命周期活动推进的质量。… 对比一个人干所有的事情，分工的结果让大家都能够得到更多。
一旦确定了问题的主体，那么系统的利益相关人就确定了下来。所发现的问题，基本上会有两种：a. 某个或者某些利益相关人时间或空间上的负载太重；b. 某个或者某些利益相关人的权力和义务不对等。
- 被切分的生命周期，如果必须要生命周期的主体在连续时间内持续执行，而且不能够被打断并更换生命周期主体的话，就不能切分出去；2. 每个生命周期的负责人，对负责生命周期的权力和义务必须是对等的；3. 切分出来的生命周期，不应该超过一个自然人的负载；4. 切分是内部活动，内部无论怎么切，对整个系统的外部都应该是透明的。
架构切分的结果最终都会体现在组织架构上，因为架构的切分是对人利益的重新分配。另一方面，架构切分需要组织架构来保障实施。负担重的相关利益人要减轻职责和权力；负担轻的相关利益人要增加职责和权力；所有人负担都很重，就要增加人，形成新的架构切分，或引进新的技术，提升大家的生产力，以形成新的架构切分。所以进行架构切分的时候，往往也就是组织在长大的时候。
从这方面可以看出，任何架构调整都会涉及组织架构。同样，如果对于利益先关人的利益分析不够透彻，也会导致架构无法落地。因为没有人愿意去损坏自己的利益，一旦强制执行，人心就容易涣散。当然，这也不一定是坏事，只要满足权责对等的原则，就能够建立一个很好的新次序和新的利益关系，保持组织的良性发展。长久来看这是对所有人都有益的，虽然短期内对某些既得利益者会有利益损害。
必须由人执行的工作。
每个人的时间有限。
对目标系统有更高的要求。
目标系统的复杂性使得单个人完成这个系统时会受限于时间。