React, Angular, Vue—pick your poison. They all have the same fatal flaw: they make you think in components, not logic. Your business rules end up scattered across 50 files, impossible to test, and locked to a framework that will be "legacy" in 3 years.
This isn't about hating frameworks. They're essential for building UIs fast. But your business logic—the rules that make your app valuable—should not live inside a useEffect hook. When you're hiring senior front-end engineers, this separation is what separates juniors from architects.
The Problem: Mixing WHAT and HOW
Most front-end code mixes two things that should never touch:
WHAT (Presentation Logic)
- —Business rules and entities
- —Domain-specific calculations
- —State transformations
HOW (Implementation)
- —React/Vue/Angular components
- —HTTP calls and APIs
- —Local storage, cookies
When these get tangled, you can't test logic without rendering components. You can't reuse code across platforms. You can't migrate frameworks without rewriting everything.
The Solution: Layered Architecture
Clean Architecture and DDD solve this by enforcing layers with strict dependency rules. Dependencies always point inward.
Layer 1: Core (Pure Logic)
Entities, value objects, and use cases. Zero dependencies on frameworks, APIs, or UI. Purely functional.
Layer 2: Adapters
Translates between the Core and the outside world. Implements repository interfaces defined in the Core.
Layer 3: Infrastructure
React components, HTTP clients, localStorage. All the "HOW" lives here. Depends on Adapters.
The MVVM Pattern in Practice
Model-View-ViewModel (MVVM) fits perfectly into this layered approach.
| Component | Responsibility | Example |
|---|---|---|
| View | Visual presentation (HTML/JSX) | <ProductList /> |
| ViewModel | Orchestrates data for the View | useProductListViewModel() |
| Model | Pure domain logic (Core layer) | Product, Cart entities |
The ViewModel is a hook or a simple function. It's trivially testable. The Model contains zero framework code—it's just TypeScript classes and functions.
Strategic DDD: Splitting by Business Domain
This is where DDD gets powerful. Instead of splitting code by file type (components, hooks, utils), you split by business domain. Consider an e-commerce platform. It now becomes organized like this:
Search, browse, catalog
Cart, payment, checkout
Delivery, tracking
Tickets, issues
Each domain has its own bounded context. The "User" entity means different things in each:
- Product:User concept is irrelevant.
- Order:User has a cart and payment method.
- Shipping:User has a list of shipments.
- Support:User has tickets and issues.
This aligns with Conway's Law: teams own domains, not components. Feature requests fall into a single team's ownership. No cross-team coordination nightmares. This is fundamental when building scalable engineering teams.
Frequently Asked Questions
Is DDD overkill for small projects?
Often, yes. DDD shines in complex domains with long lifespans. If you're building a simple marketing site or an MVP, the overhead isn't worth it. The benefits of DDD become visible in the long run—if your project is short-lived, skip it.
How does Dependency Injection work in React?
Use React Context. The Context Provider injects the actual repository (adapter) into the component tree. Components consume the context, receiving the implementation without importing it directly. This keeps your Core layer completely abstract and independent.
Can I use this with Vue or Angular?
That's the whole point. Your Core layer is pure TypeScript. It works with any framework—or no framework. You only rewrite the Infrastructure layer (the View and the adapters). The business logic (the expensive part to develop) stays untouched.
Stop Rewriting Your Front-End
Framework-agnostic architecture is insurance against the future. React won't be the dominant framework forever. When the next big thing arrives, your business logic—the valuable, tested, complex core—survives.
Building this way requires senior engineers who understand architecture, not just API calls. Read our developer vetting process to see how we find them.
Build Front-Ends That Last
We connect you with architects who understand DDD, clean code, and long-term maintainability.
Hire Front-End Architects