MVVM, Micro‑Frontends, and Domain‑Driven Frontend — A Practical Guide

This post gives you crisp mental models and copy‑pasteable patterns for three frequently‑confused topics:

• MVVM (Model–View–ViewModel)
• Micro‑Frontends (MFE)
• Domain‑Driven Design applied to the frontend (DDF/DDD)

TL;DR: Use MVVM to structure components, DDD to structure the system/domain, and micro‑frontends only when org/scale complexity requires independent deploys.

Quick Compare (When to use what)#

MVVM in React (practical)#

Model = domain data (entities/value objects).
View = React UI.
ViewModel = state + behaviors the View needs (pure, testable, no DOM).

// /features/todos/viewmodel/useTodosVM.ts
import { useState, useMemo, useEffect } from 'react'
import { fetchTodos, toggleTodo } from '../services/todoApi'

export function useTodosVM() {
  const [items, setItems] = useState([])
  const [loading, setLoading] = useState(false)
  const [error, setError] = useState(null)

  async function load() {
    setLoading(true); setError(null)
    try {
      const data = await fetchTodos()
      setItems(data)
    } catch (e) {
      setError('Failed to load')
    } finally {
      setLoading(false)
    }
  }

  async function toggle(id) {
    setItems(xs => xs.map(x => x.id === id ? { ...x, done: !x.done } : x))
    try { await toggleTodo(id) } catch {}
  }

  const stats = useMemo(() => ({
    total: items.length,
    done: items.filter(x => x.done).length,
  }), [items])

  return { items, loading, error, load, toggle, stats }
}

// /features/todos/components/TodoList.tsx (View)
import { useEffect } from 'react'
import { useTodosVM } from '../viewmodel/useTodosVM'

export function TodoList() {
  const vm = useTodosVM()
  useEffect(() => { vm.load() }, [])
  if (vm.loading) return <p>Loading…</p>
  if (vm.error) return <p role="alert">{vm.error}</p>

  return (
    <div>
      <p>{vm.stats.done}/{vm.stats.total} done</p>
      <ul>
        {vm.items.map(t => (
          <li key={t.id}>
            <label>
              <input type="checkbox" checked={t.done} onChange={() => vm.toggle(t.id)} />
              {t.title}
            </label>
          </li>
        ))}
      </ul>
    </div>
  )
}

Why MVVM here works

• ViewModel exposes only what the View needs → easier to mock/test.
• UI stays dumb; side‑effects and decisions live in the ViewModel.

Tip: A custom hook is a great ViewModel. For shared state, use a store (Zustand/Jotai) and export selectors as VM surface.

Domain‑Driven Frontend (DDD for UI teams)#

Goal: mirror business domains and bounded contexts so features don’t leak across layers.

Core ideas

• Ubiquitous Language: same terms in code and meetings (e.g., Campaign, Offer).
• Bounded Contexts: define clear borders; inside, a term has one meaning.
• Entities & Value Objects: explicit types (e.g., PhoneNumber, Money).
• Application services: orchestrate use‑cases; domain services: pure domain logic.

Foldering (Feature‑Sliced/Domain‑First)

src/
  app/                # app shell, routing, providers
  shared/             # cross‑cutting (ui, lib, api, styles, tokens)
  entities/           # reusable domain entities (User, Campaign, Money)
  features/           # user‑visible capabilities (CreateCampaign, SendSMS)
  pages/              # Next.js routes (compose features)
  widgets/            # page sections composed from features/entities

Example: Value Object

// /entities/money/money.ts
export class Money {
  constructor(readonly amount: number, readonly currency: 'EUR'|'USD'|'IRR') {
    if (!Number.isFinite(amount)) throw new Error('Invalid amount')
  }
  add(x: Money) { if (x.currency !== this.currency) throw new Error('Currency mismatch'); return new Money(this.amount + x.amount, this.currency) }
  format() { return new Intl.NumberFormat(undefined, { style:'currency', currency: this.currency }).format(this.amount) }
}

Application Service (use‑case)

// /features/create-campaign/application/createCampaign.ts
import { Money } from '@/entities/money/money'
import { CampaignRepo } from '../infrastructure/CampaignRepo'

export async function createCampaign(input: { title: string; budget: number; currency: 'EUR' }) {
  const budget = new Money(input.budget, 'EUR')
  // business rules…
  return CampaignRepo.create({ title: input.title, budget })
}

Outcome: Separation between domain and delivery (React/UI); safer refactors, clearer ownership.

Micro‑Frontends (MFE)#

Split a large UI into independently built & deployed parts. Useful for many teams, different release cycles, or poly‑stacks.

Integration styles

1. Build‑time: compose artifacts during CI (simpler, less dynamic).
2. Runtime via Module Federation: load remote bundles at runtime (webpack MF) — most common.
3. iframes/Web Components: hard isolation; tradeoffs in UX/sharing.

What to share

• Design system (tokens, components) pinned to a version.
• Contracts: types/protocols between MFEs (e.g., events, URL contracts).
• Auth & routing: centralized shell or clearly defined hand‑offs.

Minimal Module Federation sketch

// host/next.config.mjs (webpack override)
module.exports = {
  webpack: (config) => {
    const ModuleFederationPlugin = require('webpack').container.ModuleFederationPlugin
    config.plugins.push(new ModuleFederationPlugin({
      name: 'host',
      remotes: { billing: 'billing@https://cdn.example.com/billing/remoteEntry.js' },
      shared: { react: { singleton: true, requiredVersion: false }, 'react-dom': { singleton: true } },
    }))
    return config
  }
}

Routing + Ownership

• Each MFE owns its routes (/billing/**), telemetry, error boundaries.
• Shell owns the top‑level layout, auth/session, cross‑app nav.

Pitfalls & mitigations

• Duplicate deps → enforce shared versions; analyze bundle.
• Design drift → versioned DS + visual regression tests.
• Cross‑MFE state → avoid if possible; communicate via URL/events.

Use MFEs when organizational complexity dominates. If one team, one repo, don’t start here.

Putting it together#

• Use DDD to split the product into domains/bounded contexts.
• Within each domain/feature, structure UI with MVVM (custom hooks as ViewModels).
• If the org demands independent deploys per domain → consider MFEs and expose each domain UI as a remote module.
• Keep contracts explicit (types, events, URL schemas).

Diagram (text)

[ App Shell ]
   ├── [ Domain A MFE ] -- MVVM inside
   ├── [ Domain B MFE ] -- MVVM inside
   └── [ Shared DS/Auth/Telemetry ]

Decision Guide#

1. Single team, growing app? → Start with DDD foldering + MVVM.
2. Multiple teams, conflicting releases? → Add MFE for those domains.
3. Migration: carve out a bounded context → expose via Module Federation → route traffic gradually.

Testing & Observability#

• Domain tests for entities/services (pure).
• ViewModel tests for behavior without DOM.
• Contract tests between MFEs.
• E2E across shell + MFEs (Playwright).
• Telemetry per MFE: errors, web vitals, perf budgets.

Starter Folder Blueprint (Next.js App Router)#

src/
  app/
    layout.tsx
    (routes)...
  shared/
    ui/ (design system)
    lib/ (utils)
    api/ (clients)
  entities/
  features/
  widgets/

Cheatsheet#

• MVVM: put UI logic in a ViewModel (custom hook/store). Keep views dumb.
• DDD: align code with business domains and bounded contexts.
• MFE: only when org scaling needs independent deploys; share DS & contracts.
• Prefer URL/event‑based integration over shared global state.