Domain Driven Design is a software development approach that focuses on creating software that reflects the real-world business domain. It emphasizes collaboration between technical and domain experts to build a shared understanding of the problem space.

Problems DDD solves:

• Communication gaps between developers and business stakeholders
• Complex business logic scattered throughout the codebase
• Difficulty in maintaining and evolving large applications
• Lack of clear boundaries between different parts of the system
• Technical solutions that don't align with business needs

DDD provides patterns and practices to create more maintainable, expressive, and business-aligned software.

Ubiquitous Language is a common vocabulary shared between developers, domain experts, and other stakeholders. It should be used consistently in conversations, documentation, and code.

Why it's important:

• Eliminates ambiguity and miscommunication
• Makes code more readable and expressive
• Ensures business concepts are accurately represented in software
• Facilitates better collaboration between technical and non-technical team members

Example: Instead of using generic terms like "User" everywhere, use specific domain terms like "Customer," "Admin," or "Vendor" based on the context.

Entity:

• Has a unique identity that persists over time
• Identity matters more than attributes
• Mutable (can change over time)
• Equality based on identity

Value Object:

• No unique identity
• Defined entirely by its attributes
• Immutable (cannot change after creation)
• Equality based on attribute values

// Entity
public class Customer
{
    public CustomerId Id { get; private set; }
    public string Name { get; set; }
    public Address Address { get; set; }
}

// Value Object
public class Address
{
    public string Street { get; }
    public string City { get; }
    public string PostalCode { get; }
    
    public Address(string street, string city, string postalCode)
    {
        Street = street;
        City = city;
        PostalCode = postalCode;
    }
}

A Repository provides an abstraction over data access, making the domain layer independent of infrastructure concerns. It encapsulates the logic needed to access data sources.

Key principles:

• One repository per aggregate root
• Interface defined in domain layer, implementation in infrastructure
• Provides collection-like interface for accessing domain objects
• Hides database-specific details from the domain

// Domain layer interface
public interface IOrderRepository
{
    Order GetById(OrderId id);
    void Save(Order order);
    IEnumerable<Order> GetOrdersByCustomer(CustomerId customerId);
}

// Infrastructure layer implementation
public class SqlOrderRepository : IOrderRepository
{
    public Order GetById(OrderId id)
    {
        // Database-specific implementation
    }
}

A Factory encapsulates the complex logic of creating domain objects, especially when creation involves multiple steps or validation.

When to use:

• Complex object creation logic
• Multiple ways to create the same object
• Creation involves external dependencies
• Need to enforce creation invariants

public class OrderFactory
{
    public Order CreateOrder(Customer customer, List<OrderItemRequest> items)
    {
        ValidateCustomer(customer);
        ValidateItems(items);
        
        var order = new Order(customer.Id);
        
        foreach (var item in items)
        {
            var product = _productRepository.GetById(item.ProductId);
            order.AddItem(product, item.Quantity);
        }
        
        return order;
    }
    
    private void ValidateCustomer(Customer customer)
    {
        if (!customer.IsActive)
            throw new InvalidOperationException("Inactive customer");
    }
}