TDD & DDD from the Ground Up (Live Coding) - Chris Simon - NDC Sydney 2024

TDD helps ensure code quality by forcing developers to write tests first and implement the simplest solution that makes tests pass

When practicing DDD, focus on using domain language and terminology rather than technical/CRUD terms (e.g., “register student” vs “create student”)

Start with simple implementations and gradually add complexity through failing tests - don’t try to implement all requirements upfront

Keep domain logic encapsulated within domain models rather than spreading it across controllers/infrastructure code

Testing at the API boundary provides flexibility to refactor internals while ensuring external contract remains stable

Public setters on domain models often indicate business logic leaking outside the domain - prefer encapsulation

Consider business constraints (like room capacity) as part of the domain model rather than technical implementations

Race conditions and concurrency issues are often better solved through domain modeling than technical locking solutions

DDD principles can provide value even in seemingly simple CRUD applications by focusing on business language and constraints

Vertical slice architecture can work well with DDD by organizing code around business capabilities rather than technical layers

Using intention-revealing names and domain terminology in tests helps document business rules

Refactoring is safer with a strong test suite - tests should validate behavior not implementation details