As much as I greatly prefer context-based grouping when I can get it, I find it breaks down in a few significant ways:<p>Contexts are not always (or even usually?) hierarchical and distinct. This leads to constant variance on if your IAM code belongs in "users", "auth", "access", "api", or even "iam" (and is that nested under something else or not?). Or maybe it's "middleware"? Wait the identity team is called "Galactus"... Every team makes different decisions, and while all may be defensible they're still different and can take a lot of time to figure out. Assuming anyone even knows, and it isn't just rolling along vaguely on its own inertia.<p>"Directly mirrors stakeholder language" does not always have any bearing on how a thing works or is built. To take the house example, sure, houses have doors and windows. They also have stuff hidden in walls, paperwork that buyers never see, and massive supply chains that nobody actually fully knows - are you modeling those too? They're part of a house's existence. But obviously you're not because you obviously only care about X and not Y... but really, how many times have you run across a business that <i>fully agrees on what X is</i> and is completely consistent on it? Some, surely, but vague sections are often natural because otherwise your market would be a solved problem.<p>And last (OTOH) but not least: business needs and concepts often change with time. Do you restructure your code to match that? At this point you're knee deep in the first one above, <i>again</i>, and if you don't complete it you're left with confusing tech debt.<p>---<p>Type-based layouts benefit greatly from <i>not needing to think about it</i>. Almost everyone is almost immediately able to put things in the right place, and know where to go to find something. Sure, it's a bit of a mess in there, but you've still cut out like 75% of the codebase and the task is now smaller.<p>Though obviously ^ this can break down rather badly when the remaining 25% is still much too large to search quickly.