Domain-driven design forces a trade-off between three properties: domain model purity (no out-of-process dependencies), completeness (all business logic inside the domain), and performance. You can only achieve two of the three simultaneously. Using a to-do app example in .NET/C#, three implementations are shown: pure+complete (loads all entities into memory, poor performance), complete+performant (injects an abstraction into the domain, making it impure), and pure+performant but incomplete (moves business rule checks to the application layer). The author recommends the third approach for most production apps, prioritizing performance and keeping the domain model free of external dependencies, while handling concurrency concerns at the application layer.