Evolving Architecture

An effective architecture doesn’t just fit your application—it grows with it.

In this talk, we’ll explore how to design an Angular architecture tailored to your app’s current size, with a clear path for scaling as complexity increases. We’ll start small, with a single feature module, and progress step-by-step: splitting into sub-modules, grouping functionality into domains, and evolving toward a modular architecture. At the peak of this evolution, we’ll touch on microfrontends as a strategy for scaling teams and applications effectively.

Using Sheriff, we’ll also show how to enforce architectural rules, ensuring your codebase remains clean, maintainable, and scalable at every stage of growth.

Transcript

1. RainerHahnekamp Evolving Architecture Ng-Asia Rainer Hahnekamp 10. January 2025
2. About Me... https://www.youtube.com/ @RainerHahnekamp https://www.ng-news.com https://github.com/softarc-consulting/sheriff • Rainer Hahnekamp ANGULARarchitects.io NgRx Team (Trusted Collaborator) • Developer / Trainer / Speaker @RainerHahnekamp Workshops NgRx • Testing • Spring • Quality
3. RainerHahnekamp Evolving Architecture Prepared for Next Steps Adopt to changing Requirements Fits the Size
4. RainerHahnekamp Stages 1. Anarchy 2. The Split a. Container & Presentational b. Component & Services c. Container & Service & Presentational (Sheriff) 3. Independent Features a. Shared b. APIs 4. Grouped Features aka. Domain/Scope a. Feature or Domain State 5. Going Beyond a. Hexagonal b. Micro Frontends Fine-Grained Coarse-Grained
5. RainerHahnekamp Stage 1: Anarchy • Implement a minimal Prototype ◦ "Having a foundation" • Handful of elements • Basic Bootstrapping • No Routes
6. RainerHahnekamp Overengineering vs. No Plan • Uncertainties ◦ Developers ▪ Don't know how to implement ◦ End Users ▪ Don't know what they want • Certainties ◦ Authentication ◦ UI Library ◦ Backend • Dogmatics vs. Standardization • Specify First
7. RainerHahnekamp Stage 2: The Split Anarchy Container Component Presentational Component Presentational Component Anarchy Component Service
8. RainerHahnekamp Stage 2: The Split Anarchy Container Presentational Presentational Service
9. RainerHahnekamp Stage 2: The Split - The Need for Rules Feature Component UI Component Component Data Service Model Sheriff
10. RainerHahnekamp Container & Presentational Components • Also known as ◦ Smart & Dumb Components ◦ Feature & UI Components • Quick Win for Separation • Dogmatic Overuse ◦ Container Component First ◦ Presentational Component as Extraction
11. RainerHahnekamp Different Types of Presentational Components • Feature-specific ◦ Used to a single container component ◦ Specific Use-Case ◦ Part of a feature group • Shared ◦ Reusable ◦ No feature-specific types ◦ Generic
12. RainerHahnekamp State Management: Yes or No? • Local & Global State Management • Modern Tools aren't boilerplate ◦ NgRx Global & SignalStore ◦ Angular (TanStack) Query ◦ RxAngular State ◦ StateAdapt, MiniRxStore, XState, Redux for Angular • My approach ◦ Logic in Component ◦ Extract Logic to Service ◦ Switch to NgRx SignalStore
13. RainerHahnekamp Stage 3: Independent Features Feature Data UI Model Quiz Feature Data UI Model Booking Shared
14. RainerHahnekamp Stage 3: Independent Features • Features as additional layer • Need to be independent • Shared Elements • API Type for Inter-feature Dependencies ◦ 100% Independence almost impossible
15. RainerHahnekamp Stage 4: Feature Groups Brochure Data UI Model Shop Holidays Feature Data UI Model Booking Quiz
16. RainerHahnekamp Stage 4: Feature Groups (Independent Subfeatures) Quiz Data UI Model Brochure Data UI Model Shop Data UI Model Holidays Feature Data UI Model Booking
17. RainerHahnekamp Stage 4: Feature Groups (with Feature Core) Quiz Data UI Model Shop Data UI Model Holidays Core Data UI Model
18. RainerHahnekamp Stage 5: No Limits • Scaling up: Hexagonal Architecture ◦ Addresses Complexity ◦ Borrows Concepts from Hexagonal Architecture ◦ Brings Overhead ◦ Clean Code vs Cognitive Load • Scaling out: Micro Frontends ◦ Addresses Team Coordination ◦ No Sharing ◦ Technically Challenging
19. RainerHahnekamp Concepts from Hexagonal Architecture The Problem Dependency Domain
20. RainerHahnekamp Concepts from Hexagonal Architecture The Solution Dependency Domain Adapter
21. RainerHahnekamp Thanks