▶ Watch this video on YouTube (opens in a new tab)

Here's the symptom: you've got an Order class, and somewhere along the way it sprouted foreign keys, virtual navigation properties, and a bunch of attributes that have nothing to do with your business rules. It's doing two jobs at once and you stopped noticing a long time ago.

The usual explanation? "That's just how EF Core works." Reuse the class, save yourself some typing, move on.

The actual cause is more annoying. Your domain model is a tree — hierarchy, behavior, real business logic. Your database wants boxes — flat tables wired together with keys. Same concept, different shapes, different reasons to change. Cram them into one class and you get pollution, compromise, and coupling.

So you build the scaffolding to keep them apart: repository interfaces, adapters, the hidden plumbing nobody talks about. It's good architecture. I've built apps this way for years. But it's worth adding up the total weight — all of it there because we couldn't afford to store a tree as a tree.

The full cost, and where it's going, is in the video.