Angular Architecture Revisited Modernizing Angular Architectural Patterns

When I started using Angular in 2018, most architectural "rules" were already set in stone: Smart vs. Dumb components, isolated domains, and shared modules.
For years, these patterns have stood the test of time. But do they fit the simplicity of Modern Angular?
In this talk, we will put these patterns on trial. We will analyze where the classic approaches hold us back and where they still add value.
Then, we will look forward. We will discuss how Modern Angular enables new, simplified patterns, draw comparisons with how other frameworks handle state and composition, and review the tools that support this shift. Join me for a refreshing take on how to structure your next application

Transcript

1. Angular Architecture Revisited Modernizing Patterns RainerHahnekamp Spring Camp 2026
2. About Me... https://www.youtube.com/ @RainerHahnekamp https://www.ng-news.com • Rainer Hahnekamp • ANGULARarchitects.io • NgRx Core Team • Developer / Trainer / Speaker @RainerHahnekamp Open Source Projects NgRx Toolkit Testronaut NgRx Sheriff
3. RainerHahnekamp An Architectural Journey...
4. RainerHahnekamp https://go.nx.dev/angular-patterns-ebook Features are grouped in scopes
5. RainerHahnekamp https://www.angulararchitects.io/ Manfred Steyer Scopes are domains. Partial<DDD>
6. Shared Forms Grid Error Handling Widgets Backend Middleware ... App Shell Domain (Holidays ) Domain (Customers) Domain (Bookings) Domain (Diary) Layer 1 - Domain modules
7. RainerHahnekamp Layer 1 • Shell ◦ Minimum to start application ◦ Header, footer, main area ◦ Core services • Domains ◦ Isolated ◦ Minimum of communication • Shared ◦ Different types ◦ Forms, UI, Services, Grids, etc. ◦ Domains use them
8. Live Coding
9. RainerHahnekamp Holidays Feature Domain Layer 2
10. RainerHahnekamp Layer 2 • Features ◦ Drives the Use case ◦ Is on top of the domain ◦ UI components are always reusable/generic • Domain ◦ Domain Models ◦ Services for backend ◦ Logic
11. RainerHahnekamp Holidays Feature Domain Layer 2 Fabian Gosebrink I also have domain-specific UI components.
12. RainerHahnekamp *Container Components • Least Possible Template • Reading from Store • Dispatching to Store • Least Possible Typescript • No Dependency Injection, only @Input and @Output • No Observables! customers- container add-container input() output() *Presentational Components customers customer edit-container *Also known as • Smart & Dumb Components • Feature & UI components
13. RainerHahnekamp Container & Presentational Components • Advantages ◦ Works always ◦ Clear separation of concerns • Disadvantages ◦ Overhead / Dogmatic Overuse ◦ Proxy Container Components
14. RainerHahnekamp Holidays Feature UI Domain
15. RainerHahnekamp Holidays Feature UI Domain 🤔
16. RainerHahnekamp Holidays Feature Data UI
17. RainerHahnekamp Feature Data UI Model Holidays
18. RainerHahnekamp Feature UI Model Holidays
19. RainerHahnekamp Domain with multiple features Quiz Data UI Model Shop Data UI Model Holidays Core Data UI Model
20. RainerHahnekamp Domain with multiple features Quiz Data UI Model Shop Data UI Model Holidays Core Data UI Model This is lightweight???
21. Live Coding
22. RainerHahnekamp A few ideas…
23. RainerHahnekamp https://www.youtube.com/watch?v=hGzdN4OjbeA
24. RainerHahnekamp https://www.youtube.com/watch?v=hGzdN4OjbeA Stores are cheap!
25. RainerHahnekamp Alex Okrushko Marko Stanimirović SignalStore doing Container-specific tasks
26. RainerHahnekamp • Ideas from hexagonal architecture • UI is an adapter of the state • Store the center Younes Jaaidi The state is the domain
27. RainerHahnekamp https://medium.com/@dan_abramov/smart-and-dumb-components-7ca2f9a7c7d0
28. RainerHahnekamp Switching the perspective Feature Container UI Component Presentational Data Store Container as mapper between Store & UI
29. RainerHahnekamp Switching the perspective Feature Container UI Component Presentational Data Store Store does ALL the logic Feature Container UI Component Presentational Data Store Container as mapper between Store & UI
30. RainerHahnekamp Switching the perspective Feature Container UI Component Presentational Data Store Feature Container UI Component Presentational Data Store Store does ALL the logic Feature Container UI Component Presentational Data Store Container as mapper between Store & UI
31. RainerHahnekamp Switching the perspective Feature Container UI Component Presentational Data Store Role of Container??? Feature Container UI Component Presentational Data Store Store does ALL the logic Feature Container UI Component Presentational Data Store Container as mapper between Store & UI
32. RainerHahnekamp A modern/lightweight approach (Store as Hooks?) Feature Container UI Component Presentational Data Store Component Component Component Store
33. RainerHahnekamp Container & Presentational ✅ Works always ✅ Clear separation of concerns ⛔ Overhead / Dogmatic Overuse ⛔ Proxy Container Components Store & Components ✅ Works always ✅ Clear separation of concerns ✅ No Overhead / Simple ✅ No Proxy Containers
34. Live Coding
35. RainerHahnekamp Old wine in a new bottle?
36. RainerHahnekamp Old wine in a new bottle? • New Implications • Architecture based on heavyweight stores ◦ Container Component as mediator • Component hierarchies still exist ◦ All with same role • Feature Component as Route-assigned component