Grouping Code: What Angular's Style Guide Actually Asks For In short: Group by feature, not by file type — and unlike the advice you have probably read, that applies all the way down. Angular's style guide asks you to avoid , , and directories entirely. Open a legacy Angular application and you will almost always find this: This is grouping by file type . In 2016 every tutorial taught it. It is a trap at any size beyond one screen. When you organise by file type, one business requirement — "add a capacity warning to the tanker dashboard" — makes a developer open , , , and . One logical change, four root directories, and a merge conflict waiting for whoever else is in those folders today. Screaming architecture Robert C. Martin coined the term screaming architecture : your top-level directory should shout what the application does , not what framework built it. Look at and and the app is screaming "I am an Angular app!" — which you already knew. Look at and and it is screaming "I am a dairy logistics system!" — which is the useful information. The rule most people miss Here is where this lesson departs from most Angular content you will find, including earlier versions of this course. The common advice is: group by feature at the top, then group by file type inside each feature. So , , and so on. It feels like the best of both. Angular's style guide is explicit that this is not what to do: > "Avoid creating directories like , , and ." Not "avoid at the top level". Avoid, full stop. The reasoning is the same at every depth: a folder inside still separates files that change together, and it still tells you nothing about what the code does. Once a feature has fifteen components, is exactly the flat undifferentiated bucket you were trying to escape — just one level down. The structure Group by why a file exists , all the way down. Things that change together sit together. Note what is not here: no , no , no . A subdirectory exists when a component has several files that belong together, or when a feature has a sub-area big enough to name. Not because of what kind of file something is. The library (Tier 3) lives outside entirely — in — because it is a separately published package. Chapter 4 builds it. Why this wins Isolation. The billing team working on invoices will never touch a file the tanker team has open. Their workspaces are physically separate. Onboarding. A new developer fixing a bug on the tanker dashboard does not have to guess where the state lives. It is in the same folder as the screen. Safe deletion. If the business retires tanker intake next year, you delete one directory. With file-type grouping you would hunt through five folders, hoping nothing else quietly depended on a service in there. Naming. Angular's style guide asks for hyphenated file names that match the class — in — and for a component's template and styles to share that name with different extensions. There is no required suffix any more. sitting next to is unambiguous without it. Lazy loading falls out of this for free Because everything for tanker intake lives in one directory with its own routes file, the whole domain can be lazy-loaded in one line: And the feature's own routes file can provide feature-scoped state, as we saw in Chapter 1: Two notes for anyone upgrading: was removed in Angular 22, and now defaults to . If you have a workaround in place for child routes not seeing parent params, you can delete it. "But I thought a components/ folder was fine as long as it was inside a feature" This is the version of the rule almost everyone lands on, and it is a genuine improvement over the alternative — so it is easy to stop there. It also feels principled: group by domain at the macro level, group by type at the micro level. The reason it does not hold is that the file-type folder never actually earns its keep at any scale. When the feature is small, holds three files. The folder adds a level of nesting and tells you nothing. You could have put those three files directly in . When the feature is large, it holds fifteen files — and now you have reproduced the original problem in miniature. is a flat list you have to scan. Meanwhile the things that genuinely belong together are still separated: is in one folder while — which it injects, which changes with it, which is meaningless without it — is in another. Ask the concrete question: when I change how tanker volume is recorded, which files do I touch? Probably the log form, the store, and the dashboard. Under type grouping those are in three directories. Under the structure above they are within one. The subdirectories that do earn their keep are the ones named after a thing, not a category: Directory Earns its place? Why --- --- --- No A category. Splits files that change together. No Same. And usually holds one or two files. Yes A thing. Holds its , , together. Yes A thing, and a natural sub-area of the feature. Yes A domain. Yes A tier, with a rule for what goes in it. The test:…