前端开发随感

只要你实现领域模块间的松散耦合，你的应用，就是微应用，你提供的服务就是微服务，你的前端开发，就是微前端，至于最后叫什么名字，随便你 当然，注意统一语言，不管叫什么名字，别忘了限界上下文，出了你的上下文

上文中有提到，同一词汇，在不同上下文中，有不同含义 这个说法国内开发者会非常难以理解（国外的开发者也差不多），为什么？ 是因为你的母语，本身不够精确 以康熙皇帝使用过的大西字 —— 拉丁语 为例，一个

抽象 我们常见的，最能体现抽象思维的例子，就是语言 我们说出’牛‘的时候，会有一头真的牛从天而降么？不会！ 公孙龙说出：”白马非马，可乎？“的时候，不管是’白马‘和’马‘都不会从天而降！ 因为这些概念

是的，理所当然，当 SOA 问题得到解决，且很多细节已经进行了讨论 我们便直接进入了 DDD 的探讨 但是，之前我写的有关 DDD 的文章被我全部删除，因为反响不是很好，无论是在知乎还是掘金 我花了很

SOA —— 面向服务架构 是一种组件封装方式，本质上是对 功能单元的拆分，这一点与传统组件只拆分视图和内部逻辑（无法高效调用外部状态逻辑）的方式不同 而 React 如果要想实现 SOA，就需要从

上文有提到，useReducer 的 dispatch 实际上可以看成，一个封闭系统内，两个子系统融合，保证其中一个系统低熵环境的 “麦克斯韦妖”，这么说可能有点拗口，但是重点放在 维持低熵 （低状态

（但是，只在封闭系统生效！） 早些时候，我对 hooks 下使用 useReducer 或者一众状态管理库是非常方案的，带上在结合项目仔细思考之下，发现了这一方案的优点，或许结合使用才是最优解 对 u

小伙伴们在 React 开发过程中，常常会遇到组件重绘的问题，这个问题在老版本 class 写法中，通过 shouldComponentUpdate 进行优化，属于性能优化操作的一部分 但是在 hoo

任何逻辑，都可以拆分成这样的模型： 事件引起状态的变化，状态的变化又发起新的事件 “当 xxxx 发生时，xxxx 的数据会发生改变”，事件在前，状态在后，它是什么样的形式呢？ 引用 cycle.js