Clean Architecture & DDD Mastery

Entities vs Value Objects: Managing identity and state

1 Views Updated 5/4/2026

Identity and Equality

In the Domain Layer, we categorize our objects into two main types: Entities and Value Objects.

1. Entities (The Identity)

An Entity is something that has a unique ID (like a GUID or an EmployeeNumber). Even if all its other properties change, it's still the same object. A User is an Entity. If they change their name or email, they are still 'User ID 123'. Equality is checked by comparing IDs.

2. Value Objects (The State)

A Value Object has NO identity. It is defined solely by its values. Money, Address, and Color are Value Objects. If two Money objects both represent '$10 USD', they are equal. Value Objects should be **Immutable**. If you want to change an address, you don't 'update' the properties; you replace the entire object with a new one.

3. Architect Insight

Q: "Why use Value Objects instead of primitive strings/ints?"

Architect Answer: "Encapsulation. A primitive string doesn't know how to validate an Email. A EmailAddress Value Object does. By moving validation and logic INTO the Value Object, you prevent your Entities from becoming 'Anemic' (logic-less bags of data). It's the key to robust, self-validating domain models."

Clean Architecture & DDD Mastery
1. Architectural Patterns
The Evolution of Architecture: Monolith to Clean Onion Architecture: Dependency Inversion at the core Clean Architecture: The 'Screaming' architecture Hexagonal Architecture (Ports and Adapters)
2. Domain-Driven Design (DDD) Foundations
Ubiquitous Language: Aligning code with business Entities vs Value Objects: Managing identity and state Aggregates & Aggregate Roots: Defining consistency boundaries Bounded Contexts: Handling complexity in large domains
3. Advanced DDD Patterns
Domain Services: When logic doesn't fit in an entity Domain Events: Decoupling side effects via events Repositories: Mediating between domain and data Unit of Work: Ensuring atomic transactions
4. Implementing the Clean Layers
The Domain Layer: Zero dependencies, pure C# The Application Layer: Orchestrating use cases The Infrastructure Layer: Bridging to the outside world The Presentation Layer: Decoupling the UI from logic
5. Patterns for Data & Logic
CQRS (Command Query Responsibility Segregation) MediatR: Implementing the Mediator pattern in .NET Specification Pattern: Encapsulating business rules Policy Pattern: Handling complex authorization rules
6. Enterprise Domain Challenges
Handling Persistence Ignorance with EF Core Mapping Layers: AutoMapper vs Manual Mapping Validation Strategies: FluentValidation in the App Layer Error Handling: Result patterns vs Exceptions
7. Testing Clean Architecture
Unit Testing the Domain: Fast and pure Testing Use Cases with Mocks Integration Testing the Infrastructure ArchUnit .NET: Enforcing architectural rules via tests
8. Real-World Case Study
Refactoring a 'Spaghetti' Monolith to Clean Architecture DDD in Action: Modeling a complex Logistics system