2019-12-06入木三分，好文章! 10
2019-12-06老师的课程中提及的两方面是我觉得自己理解的最不好的：一方面"基础架构 + 业务架构，才是你设计的软件的全部"，另一方面"一方面从中学习怎么做需求分析，另一方面也从中体悟做架构的思维哲学"。
如同老师所说的"架构课 的革命性，我自己从没怀疑过。它的内容是精心设计的，为此我准备了十几年",学习的过程中我其实同样在整体梳理自己作为DBA&&OPS十余年松散的知识体系。老师开课的这半年多不断的适度扩展梳理去破未知，完成了20余门功课的学习；除了画图部分的知识都是在不断的循环梳理。虽不断学习和梳理，但是依然觉得老师今天课程中提及的两方面其实是最难。如同前几天DevOps课程的石老师课程提出的Plan-Do-Check-Act时，我说这个顺序其实可以改变且石老师的回复中对此非常认可一样。这个认知其实是原来许老师课程的循环反复，梳理中悟出的东西。
结合老师上堂课所提及"任何功能都是可以正交分解的，即使我目前还没有找到方法，那也是因为我还没有透彻理解需求"-可以理解为业务方面的。《全局性功能的架构设计》和《重新认识开闭原则》两章内容在强调今天课程结束老师的"基础架构 + 业务架构，才是你设计的软件的全部"。
以上是个人结合这两节课的知识对于今天课程结束部分老师的理解：谢谢老师的分享和教诲。期待老师的下次分享。展开作者回复: 作为架构师，要深刻认识到一点，光理解架构哲学不足以做好架构，它是让我们判断对与错的法则。要真正做好架构，需要做好业务需求分析，做好正交分解，做好模块边界定义。这些不断梳理清楚的“只读”的业务模块，是架构师真正的武器库。
9
2019-12-06许大，希望出书。买来收藏。
时不时枕边翻阅体会大佬的思想。
多年以后，庆幸自己这段时间跟着许大的专栏，有了新的想法和思想。作者回复: 后面应该会出书
6
2019-12-06笔记：
将开闭原则上移到业务系统。业务对外只读，意味着不可变，但不变的业务生命周期是很短暂的，所以要可扩。要扩展还要不变，就倒逼着要做兼容，而兼容可能会导致现有的功能职责不单一，这又倒逼着要对现有的功能做再抽象，以适应更广的“单一职责”。
所以不改是不可能的，只是改的结果应当是让项目往更稳定去发展。然而这里面其实好难，无论是新的抽象的定义还是职责范围的扩张，这都需要有强大的分析能力和精湛的设计思维、重构手法、调优能力以及站在核心目标上的权衡来支撑。然而难亦是乐趣所在。展开作者回复: 👍
5
2019-12-10在业务正交分解的过程中必然会遇到以前分解好的模块需要调整的情况，比如说随着新模块的加入发现和老模块的部分实现有重复的情况。这种情况下是保持新老模块的重复部分呢还是抽取出共同的部分作为更基础的支撑模块呢？如果要抽取共同的模块必然会涉及老模块的修改，这种情况是否有违反了开闭原则呢？更进一步开闭原则和重构的关系应该如何处理？作者回复: 我认为不是不修改，是不改变业务范畴，不轻易改变改变模块的使用界面
1
2019-12-08本课感受最深的一句话：
“第二，模块的业务变化点，简单一点的，通过回调函数或者接口开放出去，交给其他的业务模块。复杂一点的，通过引入插件机制把系统分解为 “最小化的核心系统 + 多个彼此正交的周边系统”。事实上回调函数或者接口本质上就是一种事件监听机制，所以它是插件机制的特例。”
由业务到数据，由核心到周边，再把这个过程映射到开闭选择，再把开放性具体到插件与接口，下节课讲接口。老师这三节课真是步步深入啊。:
偷懒得说，要是画图代码在通用一些就好了展开作者回复: 业务系统都是相通的
1
2019-12-06如何理解“只读”模块？作者回复: 不是代码只读，是业务范畴只读，接口尽可能只读（增加方法以兼容的方式进行）。
2 1
2019-12-06许老师好，很感谢您上次关于PaSS问题的回复，读您的文章让我受益匪浅。还想请教一个问题，像Salesforce是基于元数据来构建系统的，元数据在信息架构里属于什么范畴呢，可以展开来讲一讲吗？盼复。作者回复: Model 层
2 1
2019-12-13功力深厚啊- 2019-12-11许大，我们真的要考虑，将老的需求放入版本库。对于新的重新实现一个新的。
会不会最后系统会有很多名字类似业务有所区别的接口？作者回复: 这方面代码管理有很多成熟的实践了，版本管理上
- 2019-12-10感觉开闭原则跟自底向上设计很相似，都是先构建稳定的底层模块/机制，再一层层组合出来。
2019-12-06没有基本功，是很难读懂许老师的深层含义打，只能用苦功，下巧劲
2019-12-06醍醐灌顶，再多的语言也无法表达，最好的架构课
2019-12-06值回票价
2019-12-06这么一想，微服务其实也是单一职责原则的实现。像普通业务的话，不清晰以后的方向，可能现在是工具类，后来又搞商城类，侧重点变化可能无法一下子就确定那些是稳定点，做着做着又是一大坨，哪里不行搞哪里，这种怎么解？作者回复: 需求洞察本来就是架构的难点
2019-12-06基础架构 + 业务架构，才是你设计的软件的全部。作为架构师，千万不要一叶障目，不见泰山，忘记基础架构选择的重要性。 基础架构是地基
2019-12-06笔记 ocp 是根基，lsv原则用于保障ocp。 srp 让实现lsv 更简单，就一个引起变更职责代码不容易腐化。 这样出来的代码正交性更好，更容易组合。
2019-12-06通过老师的文章的一些思考。
1. 事情变得复杂往往有两个方面的原因。1.联系耦合过多 2.变化过多
2. 架构的目的就是让事情变得，简单，清晰。
3. 应对耦合过多，可以使用单一原则。
4. 应对变化过多，可以用开闭原则，而其中的"只读"，让自己有种醍醐灌顶的感觉。