Project Structure Migration Guide
Step-by-step guide for migrating to the hybrid architecture with domain-based business logic and feature-based UI organization.
Project Structure Migration Guide
Overview
This guide provides practical implementation steps for migrating from the legacy project structure to the new hybrid architecture that combines feature-based UI organization with domain-based business logic. It offers concrete examples, code snippets, and troubleshooting tips to help developers successfully transition existing code and implement new features according to the architectural guidelines.
When To Use
Use this guide when:
- Starting development on a new feature that should follow the hybrid architecture
- Refactoring existing code to align with the new architectural patterns
- Extracting domain logic currently embedded within UI components
- Creating reusable domain services that can be used across multiple features
- Resolving circular dependencies caused by incorrect code organization
Implementation Patterns
Migrating Existing Code
Analyze the Current Code Structure
Before migrating, analyze your code to identify:
- Business domain logic currently mixed with UI
- API calls that should be in domain services
- Shared utilities that are truly generic vs. domain-specific
- Circular dependencies that need resolution
Extract Domain Logic
Create a new domain directory structure and move business logic there:
Define domain types:
Create API service methods:
Creating New Features With Hybrid Architecture
Plan Domain and Feature Boundaries
Identify the domains your feature will interact with and determine what new domain entities might be needed:
Common Challenges
Circular Dependencies
Problem: You have modules that import from each other, creating a circular dependency.
Solution:
- Identify the cycle in the dependency graph
- Extract shared types to a separate file
- Use interfaces instead of direct imports when possible
Domain Boundary Decisions
Problem: Unsure where to place code that seems to belong to multiple domains.
Solution:
- Identify the primary responsibility of the code
- Consider which domain would be most affected by changes to this code
- If truly shared, create a new domain or place in appropriate shared folder
Refactoring Large Components
Problem: Large components with mixed concerns are difficult to migrate.
Solution:
- Start by extracting pure UI components
- Move data fetching to custom hooks
- Extract business logic to domain services
- Finally, reconnect using the clean architecture pattern
Performance Considerations
Minimize Re-renders
- Use selector functions when accessing domain state to prevent unnecessary re-renders
- Consider memoization for expensive calculations
- Keep state updates granular to avoid cascading re-renders
Lazy Loading Domains
For large applications, consider implementing lazy loading of domain logic:
Examples
Full Migration Example: User Profile Feature
This example shows how to migrate a user profile feature from the old structure to the new hybrid architecture:
After migration:
This migration:
- Separates domain logic (data types, API calls) from UI concerns
- Uses TanStack Query for data fetching and caching
- Makes testing easier by isolating business logic
- Improves reusability of the user profile functionality
Related Resources
- project-structure - Comprehensive reference for the project's directory structure
- core-architecture - Overview of the application's hybrid architecture approach
- State Management Implementation Guide - Implementation patterns for client state
- Server State Management Guide - Implementation patterns for server state