词语的意义是由上下文决定的。例如，“角”这个词语可以出现在讨论几何学的上下文中，也可以出现在零钱的上下文中，分别表示完全不同的意思。在软件开发中，软件工程师使用得驾轻就熟的命名空间也起到了上下文的作用。

接前文，在进行应用的横向扩展时，至少有三类问题是比较难以解答的 如何保证拆分软件模块的正确性？如何保证数据库的拆分不会降低性能？如何对待分布式系统中的一致性等问题？ 在实现中，这三个问题可以分别被具体化为： 怎样证明一些代码和另一些代码有很强的相关性...

Microservice是微型－服务的合成词，一个近年来很新的buzzword。Buzzword意为每个人都喜欢讲的流行术语（大数据是另一个有趣的buzzword）。

你需要更严格一点定义“强一致” 因为每台机器上的时间就不可能严格一致，不到一毫秒的差距就足够你在两台机器上的代码跑到不同分支去了

为了节省人力，很多应用会使用网站框架以实现工程级别的继承关系：把问题从制作“Java网站应用”变成制作“Java EE”或者“Spring”应用，从而复用父类（框架）的经验和代码。

import/export是语言的一部分，将来扩展性可能好点 而且es6模块系统不能动态引入模块，没有require('/lib'+libName)这种写法，多少可以防止滥用。 如果有需要动态加载的依赖，就用DI吧

像Flux Redux这类模式，通过牺牲自由度使得对象间的数据流变得更清晰。跟来源于数学的函数语言没什么关系，只是在“限制副作用”这点是跟函数语言一样的。可以看成把之前解决复杂性的经验在前端领域结合起来，然后起一个新名字。

React是界面库，你可以用自己的方式去探索自己的最佳实践。官方推荐的模型是Flux（我尝试了一下，最后的结果跟Flux差不多）。 剩下的都是自带最佳实践的吧，Angular是TDD，Backbone不了解，Ember是MVC加上JSONAPI。 喜欢探索用React不会错的，而且很好学，学会不到十...

大部分数据的唯一真相（SSoT）在后端，前端的Store只需要也只应该把后端的数据显示出来，作为缓存之类。 为了显示这类数据而做的请求可以放在Store里面，因为是不应该失败的请求。 同意你的其他观点。