Where should business logic live in a .NET application, and how do you avoid both an anemic domain model and entities that do everything?

In production I choose aggregate boundaries from consistency needs, not object graphs. A large aggregate can cause contention and expensive loading, while a tiny one may fail to protect an invariant. Cross-aggregate workflows may need a process manager, reservation, or eventual consistency instead of one giant transaction. I keep persistence mapping from dictating public domain behavior and test invariants without a database. Telemetry belongs around the use case, while domain events can describe completed decisions without directly publishing to infrastructure. The model earns complexity only where the business has complexity.