How We Solved Complex Frontend Data Flow with MobX and DDD

Data flow has always been a problem in front‑end development; we have distilled a set of best practices and welcome discussion.

In the legacy Done project the codebase became highly tangled, making even simple features take 2–3 times longer to implement. The business characteristics we identified are:

Strong domains (e.g., project, file, team, user) that are accessed by many components.

Complex single‑page applications with many nested components and heavy inter‑component communication.

Rapid growth from 0→1 to 1→n, leading to a surge in feature requests, large front‑end changes, and a manpower bottleneck.

From these traits we observed the following problems:

Excessive boilerplate code hurting development efficiency and maintainability.

Spiral‑shaped, tightly‑coupled data flow causing a sharp rise in complexity.

Globalized data.

Conversion between raw data and presentation data.

UI tightly coupled with data logic, resulting in low reuse.

Our goals were to keep the solution simple and efficient, reject boilerplate, reduce code complexity, and improve reuse.

1. UI‑Logic Coupling & Data Transformation

The original architecture mixed store and view layers, leading to high coupling and low reuse. We introduced an independent Store layer to encapsulate business data and logic, allowing multiple components to share the same logic while keeping the view layer separate.

Separating concerns means that changes in the Store layer do not require view changes, improving maintainability.

We also added an API anti‑corruption layer to handle data conversion between backend services and the front‑end. When backend fields change, only this layer needs updating.

2. Mesh‑like Data Flow

Even after separating Store and view, the project still suffered from mesh‑like data calls. For example, muting a project triggered updates across unrelated components due to a shared global Redux store.

We re‑architected the Store hierarchy so that stores at the same level cannot call each other; cross‑level calls must be promoted to a higher level, dramatically simplifying dependencies.

After refactoring, a few lines of code are enough to handle the mute action, and each view component updates itself independently.

3. Global State Overuse

Sharing state between non‑parent/child components via prop drilling leads to unnecessary intermediate props. To avoid this, we initially moved state to a global Redux store, but this introduced its own problems, especially for transient UI state.

We evaluated MobX, which naturally supports multiple stores and aligns with our domain‑driven design (DDD) approach.

4. Domain‑Driven Design (DDD)

Using DDD, we abstracted domain models such as “File” with operations like rename, delete, and move. The view layer only assembles UI, while the stable domain model handles business logic, making the system flexible and maintainable.

We organized stores into three layers, with the smallest granularity being module‑level stores, reducing the number of shared ancestors and improving stability.

MobX’s advantages—minimal boilerplate, TypeScript friendliness, support for both hooks and classes, and natural multi‑store architecture—made it the optimal choice after evaluating alternatives like unstated‑next and Redux.

Technical Selection

Reasonable layering separating UI and logic.

Fine‑grained store granularity with DDD.

Eliminate template code to boost efficiency.

Future‑proof and compatible with legacy code (hooks & classes).

Better TypeScript support.

In summary, there is no universally best technology; the best solution fits the business context. By addressing each pain point, we built a MobX‑based architecture that has been running in production for months with positive results, enhancing development speed and maintainability.