What is the role of testing in Domain-Driven Design?

In Domain-Driven Design (DDD), testing strategy aligns with the architecture. (1) Domain model unit tests: the richest part to test — pure domain logic, aggregates, value objects, domain events, domain services. These are completely isolated (no mocks needed — domain objects have no infrastructure dependencies). Use TDD here — tests drive the domain model design. Example: var order = new Order(); order.AddItem(product, 2); Assert.Equal(2, order.ItemCount);. (2) Application service integration tests: test use cases/application services with real repositories but mocked external services. (3) Repository integration tests: test the repository implementations against a real database (Testcontainers). (4) Anti-corruption layer tests: verify translation between bounded contexts. (5) Domain event tests: verify events are raised on state changes. Bounded contexts define natural test boundaries — each context tests independently. The hexagonal architecture (ports and adapters) makes domain testing natural: the domain has no infrastructure dependencies, so pure unit tests are easy to write.