Refactor backend to follow Domain-Driven Design (DDD) principles

[Copilot]

Overview

This PR refactors the backend architecture to follow Domain-Driven Design (DDD) principles, providing a cleaner separation of concerns and more maintainable codebase while maintaining full backward compatibility.

Problem

The previous architecture had several issues:

• Anemic domain model: Entities were just data containers with public setters
• Mixed concerns: Business logic scattered across controllers and services
• Unclear boundaries: No clear separation between domain, application, and infrastructure layers
• Difficult to test: Business logic tightly coupled with infrastructure

Solution

Restructured the backend into clear DDD layers:

📦 Domain Layer (Blog.Core/Domain)

Rich Entities with Business Logic

// Before: Anemic entities with public setters
public class User {
    public string Email { get; set; }
    public string PasswordHash { get; set; }
}

// After: Rich entities with encapsulated behavior
public class User {
    public Email Email { get; private set; }
    public HashedPassword PasswordHash { get; private set; }
    
    public static User Create(string name, string email, string password) { ... }
    public bool VerifyPassword(string password) { ... }
}

Value Objects

• Email: Validates email format and ensures consistency
• HashedPassword: Encapsulates password hashing and verification logic

Repository Interfaces

• Moved from UseCases/ to Domain/Repositories/ following DDD conventions
• Contracts defined in domain, implemented in infrastructure

🎯 Application Layer (Blog.Core/Application)

Use Case Services

• UserService: Orchestrates user registration and login workflows
• JwtService: Handles JWT token generation
• Services coordinate domain objects without containing business rules

🔧 Infrastructure Layer (Blog.IO)

Database Persistence

• Updated BlogDbContext with EF Core value object conversions
• Repository implementations use new domain entities
• No database schema changes required - maintains full compatibility

🌐 Presentation Layer (Blog.Web)

Controllers

• Thin controllers delegate to application services
• Updated to use new domain namespaces
• Error handling for domain validation exceptions

Key Benefits

• ✅ Better Testability: Domain logic isolated from infrastructure
• ✅ Improved Maintainability: Clear boundaries between layers
• ✅ Enhanced Flexibility: Easy to swap infrastructure without touching domain
• ✅ Business Focus: Code reflects business language and rules
• ✅ Protection: Encapsulation prevents invalid states

Backward Compatibility

• ✅ No breaking API changes
• ✅ Database schema unchanged - existing migrations remain valid
• ✅ Value object conversions maintain data compatibility
• ✅ All existing endpoints work identically

Documentation

Added comprehensive DDD_ARCHITECTURE.md documenting:

• Project structure and layer responsibilities
• DDD principles applied
• Code examples and patterns
• Migration compatibility notes

Testing

• ✅ All builds pass successfully
• ✅ Code review completed - all comments addressed
• ✅ Security scan passed (0 alerts)
• ✅ No compilation errors

References

• Clean Architecture by Example
• Domain-Driven Design by Eric Evans

Original prompt

Rewrite backend so core follows DDD

---

💬 Share your feedback on Copilot coding agent for the chance to win a $200 gift card! Click here to start the survey.