引言 当前端业务复杂度上升到一定程度的时候，如何提升前端代码质量便成了老生常谈的话题。似乎前端总逃不开改他人代码，重构，修复bug的宿命。那么，我们要如何从项目代码层面，改变这一局面呢？才能保证项目A

mobx是一款基于观察者模式的响应式数据管理框架，相对于redux来说是后起之秀。 有一种观点认为mobx不适合构建大型项目，这源于mobx过于灵活的特点。灵活即意味着随意，这在开发日益复杂的大型项目是致命的弱点。redux则不然，它的唯一数据源、reducer纯函数、只能通过…

背景：在旧的 Done 项目中，代码复杂度高，已经到了“牵一发而动全身”，技术债极高的情况。由于旧代码“错综复杂”，导致实现一个简单的功能，都需要比正常时间多2～3倍的工作估时。就像下面这张图的情况一

大型应用的场景本文旨在分享一些对于状态管理的思考与抉择，在展开之前，我们先来定义一下何为“大型应用”。以笔者本身为例，日常的工作在维护公司内部的一款BI分析平台，从前期的数据源筛选，数据加工，到分析过

实践DDD的第一步不在于如何编写代码，而首先需要拉齐对领域驱动设计的认知。后续的系列文章将围绕领域驱动设计进行不同视角探讨，以期帮助大家对其有更深入的认识，并能应用的实际的研发工作中。

长期以来前端只关注于页面展示和交互，而如今前端承担了越来越多的业务逻辑，将领域驱动设计应用于前端十分有必要。 软件开发需要考虑的因素太多：后端的数据库，环境，界面交互，不同客户端，鉴权，经常变动的需求等，难以将精力集中在核心的业务逻辑上。 模块边界不清晰，牵一发而动全身。经常变…

随着我们解决的场景越来越专业化和复杂化，大型SPA应用的流行，前端承担的职责越来越多。很容易导致迭代着迭代着发现代码改不动了。最后只能新起炉灶，重新开发。归根到底在于 复杂度的失控...

它是一种非常方便的方案，可以帮助你解耦你的代码。让层、模块和服务尽量独立。不仅可以独立发布、部署，还可以让你从一个项目迁移另一个项目的时候也更加容易。

背景 DDD领域驱动设计，在后端领域，现在应用非常广泛，在我看来，前端（特别是React）也是非常适合DDD