Vue Soc的详解
1,为什么要提SOC这种宏大概念？
都被袁隆平教授喂得太饱么， 并不是…
有些容易被忽视和错过的简单规则、代码框架介绍中，一言带过的知识，对我们来说却是极其珍贵，我们团队做的底层PAAS架构，所需的视角和需求都极为宏大。
面试中，我会提到IOC的问题， 这个问题是，控制反转，谁反了？ 谁是控制一方？ 谁是被控一方，现实生活中，有相关的案例吗？ —— 最后一问，很多经验丰富的人，都回答得不好。
—— 我们谈的原则， 谈的理论，只有计算机领域里面用到了？ 你确定学科之间，顶层的设计逻辑会如此肤浅吗？ 不会， 要做好一个大平台， 就要深入消化通用理论。
SOC跟我们目前至少是相关的， 我们的前端VUE框架开篇，就讲到了VUE的特性， 开篇介绍，就提到了SOC和渐进式架构。 渐进式我们下回再提，先谈谈SOC.
武侠书(IT公司都喜欢谈武侠，比如阿里巴巴)里面有很多场景， 就是初入江湖的小生，拿着祖传的心法秘诀， 背得滚瓜烂熟，但常常被现实的王八拳打得落花流水，武功再高，也怕飞一般的菜单，因为【天下武功，唯快不破】， SOC并没有写到23中设计模式， 但其造诣是非常深刻的。
强调架构设计，要错落有致的分离变化点。
所有的设计， 最终就是要应对变化，什么变化？ 不同客户的变化， 客户今非昔比的变化，真实场景和办公室设计的变化。—— 不断的被现实抽打，不断的被自己的偏狭打脸。—— 这一点，在我们公司体现的淋漓尽致。 其他公司，单个项目，我想，一定没有如此深刻。痛苦且真实的发生着， 痛并快乐着，你在人生刚刚开始的阶段， 了解到这些复杂， 会呈现给你更加成熟的人生。
去污染原则， 系统中一个部分发生了变化，不会影响到其他的变化。
jinglintu的变化，没有影响到kadingche，为什么？ 一个跟卡丁车完全类似的项目， 我们怎么代价最小的搞定他？ 比如zhiwei、jiheng他们之间是派生关系，派生关系，如何稳妥的去污染？
看看VUE是怎么做到SOC的:
【后面补充:】
具体说明（概念比较难理解）
好的架构设计必须把变化点错落有致地封装到软件系统的不同部分。要做到这一点，必须进行关注点分离。
好的架构必须使每个关注点相互分离，也就是说系统中的一个部分发生了变化，不会影响其他部分。
即使需要改变，也能够清晰地识别出那些部分需要改变。
如果需要扩展架构，影响将会最小化，已经可以工作的每个部分都将继续工作。
上述论述中的四句话总结：
- “系统中的一个部分发生了变化，不会影响其他部分。”
- “即使需要改变，也能够清晰地识别出那些部分需要改变。”
- “如果需要扩展架构，将影响最小化，已经可以工作的每个部分都将继续工作。”
这里讲的是什么呢？ 要把一件事件做好，就要有你自己的专注点。
每一部分会有各自的关注焦点。模组化程度，也就是区分关注焦点，
1974年，艾兹赫尔·戴克斯特拉在他的文章《On the role of scientific thought》中提出:
让我告诉你，对我来说所有聪明的思考的共通特性是什么。一个人要有系统地深入研究一门课题；必须将这们课题独立出来，记住在任何时候都只能关注其中一个方面。 比如说，我们知道一个程式必须是正确的，因此我们可以只抓这个点来研究；我们同时也清楚它应当是高效率的，我们可以改天来研究它的效率，等等。我们也可以问自己，程式是否是可取的（desirable）？如果是，为什么？相反的，同时应对好几个个方面不会得到任何结果！这就是我有时提到的“the separation of concerns（关注点分离）”。这个技巧就算不是完美可行的，也仍是我知道有效地组织思维的唯一可用技巧。这是就是我说的“将一个人的注意力集中在几个方面上”。这并不是说忽略其他方面，只是表明从这个方面来看，其他方面并无关紧要这一事实。这即是同时拥有单任务和多任务思维。
15年之后，这个概念已经被人们所接受。1989年，Chris Reade写的《Elements of Functional Programming》有这样的描述[6]：
一个程式在执行的时候一定会同时做以下几件事情：
参考文献:
【1】WIKI关注点分离