> Type-based grouping is great for tech-focused tasks, consistent naming, and large sweeping changes.

> Context/process-based grouping shines for domain clarity, team ownership, debugging, and mapping business problems directly to code.

  app/
    iam/
      orgs/
        models.xyz
      roles/
        models.xyz

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.

"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 fully agrees on what X is and is completely consistent on it? Some, surely, but vague sections are often natural because otherwise your market would be a solved problem.

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, again, and if you don't complete it you're left with confusing tech debt.

---

Type-based layouts benefit greatly from not needing to think about it. 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.

Though obviously ^ this can break down rather badly when the remaining 25% is still much too large to search quickly.

> Maybe tomorrow. Maybe in six months. But change is coming faster than your next caffeine crash from the coffee you had this morning. Smart developers accept this upfront and set up their projects to embrace it, not fight it.

...this does depend on the project. If you're developing a video game, for example--a single player game like Zelda, not a service game like Fortnite--there actually is a point where your code won't change. Similarly, I used to work at an agency that specialized in one-off static websites tied to particular moments in time. While we did sometimes modify these websites post launch, the edits were minor and generally meant something had gone wrong, either on our end or the client's.

This is kind of unfair to the author. I point this out only because I think it's important to acknowledge that some software really is one and done, and it's important to know what kind of project you're doing. YAGNI and all that.