Stop Letting Your UI Suffer Because of Your API: Meet DVMM

You’ve probably been there: the backend team changes a field name or nests some data differently, and suddenly your beautiful frontend is throwing errors like it’s its full-time job.

Enter DVMM – the Domain-View Model Mapper pattern – a lightweight frontend architecture I started using to keep projects clean, decoupled, and easier to scale. It’s not a framework, just a simple approach I put together while trying to solve the age-old API vs UI mismatch mess.

Let me walk you through what DVMM is, where it fits, and how it might help you the way it helped me (and a few teams I’ve worked with).

---

What is DVMM

DVMM is a TypeScript-friendly frontend architecture pattern I’ve been using (and refining) in my projects to deal with messy data flows between backend APIs and the UI. Over time, it became clear that a clean separation of concerns not only makes code easier to maintain, but also improves developer sanity.

The core idea is simple:

• Domain Models – the raw data structure you get from your API.

• View Models – the data structure your UI components actually need.

• Model Mappers – the translators that convert between Domain and View models.

Think of it as MVVM’s frontend cousin — but laser-focused on strong typing, readable code, and a folder structure that doesn’t make you cry.

I originally came up with DVMM to solve recurring headaches in projects with fast-evolving backends and complex UIs. While I think it’s a solid pattern, it’s still growing — and I’d love for others to build on it or adapt it to their needs.

---

Why Use DVMM?

Let’s be honest, your API response is rarely exactly what your UI wants.

You might get:

{
  "id": "1",
  "name": "Alice",
  "avatar_url": "/alice.png",
  "joined_at": "2025-06-01T10:00:00Z"
}

But in your component, you really want:

{
  id: "1",
  displayName: "Alice",
  avatarUrl: "/alice.png",
  joinedDate: new Date("2025-06-01T10:00:00Z")
}

That’s where DVMM shines — it lets your UI work with exactly what it needs, while isolating the backend messiness.

---

The Folder Setup

Here’s a folder structure I usually go with:

📦 src
├── 📂 data
│   ├── 📂 domain
│   │   ├── 📂 models       🧩 Domain Models (API response types)
│   │   ├── 📂 functions    🔌 API Call Functions
│   │   ├── 📄 client.ts    🌐 API Client Setup (Axios / Fetch / Ky)
│   │   └── 📄 index.ts     🧠 Domain Logic Entry Point
│   ├── 📂 view
│   │   ├── 📂 models       🎨 View Models (UI-specific data)
│   │   ├── 📂 mappers      🔁 Domain ↔ View Model Mappers
│   │   └── 📄 index.ts     🎯 View Logic Entry Point
├── 📂 components           🧱 Reusable UI Components
└── 📂 pages                📄 Application Pages (Routes)

It keeps things tidy and helps new devs onboard quickly.

---

Real-World Example: Blog Posts

Here’s a simplified version of what a blog post might look like with DVMM:

Domain Model (for API Client)

export interface PostDomainModel {
  id: string;
  title: string;
  content: string;
  published_at: string;
}

View Model (for UI)

export interface PostViewModel {
  id: string;
  title: string;
  content: string;
  publishedAt: Date;
}

Model Mapper

export class PostMapper {
  toViewModel(domain: PostDomainModel): PostViewModel {
    return {
      id: domain.id,
      title: domain.title,
      content: domain.content,
      publishedAt: new Date(domain.published_at),
    };
  }

  toDomainModel(view: PostViewModel): PostDomainModel {
    return {
      id: view.id,
      title: view.title,
      content: view.content,
      published_at: view.publishedAt.toISOString(),
    };
  }
}

Now your component gets exactly what it needs, and your backend contracts are cleanly abstracted away.

---

When Should You Use DVMM?

• ✅ When your backend changes often and breaks your UI too frequently

• ✅ When your UI needs to shape or format data differently

• ✅ When you care about type safety and maintainability

• ✅ When frontend and backend teams work separately

• ✅ When you want your codebase to grow without getting messy

---

Bonus: Dev Team Peacekeeping

DVMM also reduces the back-and-forth noise between frontend and backend folks.

Backend devs can tweak their response format or rename a field, and instead of a UI fire drill, all you need is a small mapper update.

---

🚀 TL;DR

DVMM is a small idea that made a big difference for me. It creates a clean line between what your API gives you and what your UI needs — and that’s huge in fast-moving projects.

If you’re working on a modern TypeScript frontend (especially with React or Vue), this pattern might help you write cleaner code, work faster with your team, and reduce bugs you didn’t know you were inviting in.

---

Thanks a ton for reading all the way through! 🙌 I hope DVMM gives your frontend a little more breathing room. If you try it out or have thoughts, I’d love to hear from you!