Praktische hoekige architectuur voor het echte leven

Bij de meeste cursussen Angular-architectuur wordt theorie gegeven. Niet deze.

Hier leer je echte problemen op te sporen, gerichte beslissingen te nemen en systemen te bouwen die standhouden als het team groeit, het product verandert en de tijd verstrijkt.

Twintig modules. Praktijkgericht. Geen vulling.

---

INDEX — Praktische hoekige architectuur voor het echte leven

---

Module 0 — Systeembasis

Punt 0 is geen inhoudsmodule. Het is de manier van kijken die je gedurende het hele stappenplan zult gebruiken.

Voordat u over specifieke problemen in Angular praat, moet u een vraag beantwoorden:

Hoe kijk je naar een app die je niet kent en beslis je of deze goed of slecht is?

Daar zijn vier basisvaardigheden voor.

---

1. Analyseer een app zonder code aan te raken

De eerste lezing van een app vindt niet plaats in de editor. Het zit in de structuur. Voordat u een enkel bestand opent, kunt u informatie extraheren:

• Hoe heten de mappen? Zeggen de namen wat ze doen?
• Is er een map shared die meer weegt dan al het andere?
• Hoeveel nestniveaus heeft de structuur?
• Hebben de modules of features domeinnamen of technische namen?
• Waar zijn de diensten? Los of binnen de kenmerken?

Dit vertelt je al veel over de vraag of degene die de app heeft gemaakt in zakelijke termen of in termen van technische lagen heeft gedacht.

---

2. Architectuur op een praktische manier beoordelen

Reviewen is niet het van boven naar beneden lezen van code. Het stelt vragen met criteria:

• Waar leeft de bedrijfslogica?
• Wie weet wat in elke laag?
• Hoeveel sites moet u wijzigen om een ​​nieuwe functie toe te voegen?
• Zijn er afhankelijkheden die de verkeerde kant op gaan?

Een senior architect begint niet met het meest complexe onderdeel. Begin met de punten met het hoogste risico: gedeelde services, de mondiale status en de laag voor gegevenstoegang.

---

3. Detecteer problemen vóór het programmeren

De meeste architectonische schade ontstaat bij vroege beslissingen die irrelevant lijken:

• "Ik zet dit voorlopig op een gedeelde service"
• "De bovenliggende component verwerkt deze status, daarna verplaatsen we deze"
• "We gebruiken NgRx voor alles, dus het is consistent"

Deze beslissingen hebben maanden later echte gevolgen. Het architecturale criterium is om te weten wat elke beslissing oplevert en welke schulden het met zich meebrengt.

---

4. Zet theorie om in echte checklist

Elk concept dat we in deze routekaart zullen zien – slimme/domme componenten, plaatsing van de staat, goddelijke diensten, enz. – moet eindigen in een vraag die je jezelf kunt stellen terwijl je echte code beoordeelt:

• Weet dit onderdeel waar de data vandaan komen?
• Heeft deze service meer dan één reden om te veranderen?
• Bestaat deze toestand op twee verschillende plaatsen?

Als je van een concept geen beoordelingsvraag kunt maken, heb je het nog niet geïnternaliseerd.

---

Module 1 — Een Angular-app analyseren zonder code aan te raken

De eerste architectuurbeoordeling vindt plaats voordat de editor wordt geopend. Alleen al uit de mapstructuur en bestandsnamen kun je al duidelijke kwaliteitssignalen afleiden. Dit is wat een senior architect de eerste 10 minuten zou doen met een onbekende app.

Waarom maakt het uit?

• Als het lang duurt om architectonische problemen op te sporen, stijgen de kosten voor het corrigeren ervan exponentieel.
• Een slecht ontworpen structuur vanaf dag 1 wordt een technische schuld die het team maanden later blokkeert.
• Door een snel visueel oordeel te ontwikkelen, kunt u betere beslissingen nemen voordat u ook maar één regel code schrijft.

Stap 1 — Lees de mapstructuur als een kaart

De mappenstructuur is de eerste zichtbare architectonische beslissing. Het vertelt je hoe het team hun mentale wereld heeft georganiseerd: denken ze in termen van technologie of in termen van business?

Wat is een functie?

Een feature is een complete bedrijfsfunctionaliteit. Geen bestandstype. Geen technische laag.

Denk aan een e-commerce-app. De kenmerken zijn:

• De productcatalogus
• Het winkelwagentje
• Het afrekenproces
• Het gebruikersprofiel
• Orderbeheer

Elk van deze is een onderdeel van het bedrijf dat op zichzelf zinvol is. Een gebruiker komt binnen, bladert door de catalogus, voegt toe aan winkelwagen, rekent af. Dat zijn kenmerken.

Model 1 — Organisatie per technische lagen (problematisch op schaal)

Dit is wat bijna iedereen doet als ze beginnen, omdat het er netjes uitziet:

src/app/
  components/
    product-card.component.ts
    product-list.component.ts
    cart-item.component.ts
    checkout-form.component.ts
    user-profile.component.ts
  services/
    product.service.ts
    cart.service.ts
    checkout.service.ts
    user.service.ts
  models/
    product.model.ts
    cart.model.ts
    user.model.ts

Het echte probleem: u moet het afrekenproces aanpassen. Om te begrijpen wat het inhoudt, navigeert u tussen drie verschillende mappen: u zoekt naar het onderdeel in components/, de service in services/, het model in models/. Als er een specifieke kassapijp is, wordt deze in pipes/ gemengd met pijpen van andere features.

Om één functie te wijzigen, navigeer je door de hele app. Dat is koppelen door structuur. Wanneer het team groeit, raken twee mensen die aan verschillende functies werken voortdurend dezelfde mappen aan → conflicten in git, moeite om te weten wie wat bezit.

Model 2 — Organisatie op basis van kenmerken (welke schaal)

src/app/
  features/
    catalog/
      components/
        product-card.component.ts
        product-list.component.ts
      services/
        product.service.ts
      models/
        product.model.ts
      catalog.routes.ts
    cart/
      components/
        cart-item.component.ts
        cart-summary.component.ts
      services/
        cart.service.ts
      cart.routes.ts
    checkout/
      components/
        checkout-form.component.ts
        order-confirmation.component.ts
      services/
        checkout.service.ts
      checkout.routes.ts
  shared/
  core/

Waarom dit werkt: Wanneer u op afrekenen tikt, staat alles bij het afrekenen bij elkaar. Een nieuwe ontwikkelaar weet precies waar hij moet zoeken. Eén persoon kan eigenaar zijn van een hele functie. U kunt een geheel object verwijderen door alleen de map ervan te verwijderen. Git-conflicten tussen verschillende features verdwijnen vrijwel volledig.

De belangrijkste vuistregel: als u een element verwijdert, kunt u dan de hele map ervan verwijderen zonder iets anders aan te raken? Als het antwoord ja is, is het kenmerk goed geïsoleerd. Als je in de app naar stukjes moet zoeken, is dat niet het geval.

Stap 2 — Lees de namen

Namen zijn documentatie. Een slechte naam verbergt bedoelingen en voegt cognitieve belasting toe aan elke persoon die de code leest.

shared/ — wat er wel en niet in moet staan

shared/ is voor dingen die meerdere functies gebruiken en die GEEN eigen bedrijfslogica hebben.

Corrigeren in shared/:

shared/
  components/
    button/
    modal/
    spinner/
    avatar/
  pipes/
    date-format.pipe.ts
    truncate.pipe.ts
  directives/
    click-outside.directive.ts
  validators/
    email-validator.ts

Het zijn herbruikbare UI-onderdelen of pure hulpprogramma's. Ze weten niets van het bedrijf. Een ButtonComponent weet niet of het een betaalknop of een gebruikersprofielknop is. Hij weet alleen hoe hij een knop moet zijn.

Onjuist in shared/:

shared/
  services/
    cart.service.ts           ← lógica de negocio aquí
    user-auth.service.ts      ← pertenece a auth/core
    product-filter.service.ts ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

Als u services met bedrijfslogica in shared/ ziet, betekent dit dat iemand niet wist waar hij ze moest plaatsen. Na verloop van tijd wordt shared/ de verzamelnaam van de app.

core/ — wat het is en wat het niet is

core/ is voor singleton-infrastructuur waarvoor de hele app één keer nodig is.

Corrigeren in core/:

core/
  services/
    auth.service.ts
    logger.service.ts
    error-handler.service.ts
  interceptors/
    auth.interceptor.ts
    error.interceptor.ts
  guards/
    auth.guard.ts
  models/
    user-session.model.ts

Onjuist in core/:

core/
  components/
    dashboard.component.ts  ← eso es una feature
    home.component.ts       ← igual
  services/
    product.service.ts      ← pertenece a catalog
    report-generator.service.ts ← pertenece a reporting

Dit zijn dingen die één keer worden geïnstantieerd en die de hele app beïnvloeden. De authenticatie-interceptor onderschept alle HTTP-verzoeken voor de hele app en bevindt zich daarom in core/.

Vage namen – rode vlaggen

Een vage naam is een uitgestelde beslissing. Wanneer iemand data.service.ts maakt, heeft hij nog niet besloten over welke gegevens de service het heeft.

wat je ziet	Wat het kan betekenen
shared/ heel groot	Alles wat nergens anders paste. Het wordt een allegaartje.
common/	Hetzelfde als shared/, maar slechter genoemd. Zonder criteria van wat erin gaat.
utils/ met diensten	Bedrijfslogica vermomd als nutsvoorziening. Ernstige rode vlag.
helpers/	Hetzelfde als utils/. De naam zegt niets over verantwoordelijkheid.
components/ in hoofdmap	Geen organisatie per domein. Alle componenten bij elkaar.
core/ met 40 bestanden	Slecht gedefinieerde kern. shared/ werd gebruikt als tweede.
app.service.ts	Een godsdienst die wacht om te groeien. Maximaal alarmsignaal.
data.service.ts	Gegevens waarover? Onbepaalde verantwoordelijkheid vanwege de naam.
helper.service.ts	Het wordt uiteindelijk een service met niet-gerelateerde methoden.
main.component.ts	Wat is "belangrijkste"? Algemene naam die echte verantwoordelijkheid verbergt.

Naamregel: Als de bestandsnaam niet precies vertelt wat het doet, doet het bestand waarschijnlijk te veel of is het slecht gelokaliseerd.

Concrete voorbeelden van vage namen en wat ze verbergen:

• utils/format.ts met 800 regels: mix van datumopmaak + formuliervalidatie + API-transformatie.
• helper.service.ts: wordt uiteindelijk een godsdienst met niet-gerelateerde methoden.
• app.service.ts: een dienst genaamd de hele app die verantwoordelijkheden heeft voor de hele app.

Stap 3 — Tel en meet zonder bestanden te openen

Voordat u code leest, kunt u deze observaties rechtstreeks vanuit de structuur maken:

Onderdeelgrootte als teken

Teken	Wat geeft het aan?
+300-400 regels in één component	Je doet bijna altijd te veel. Het is geen absolute regel, maar het is de moeite waard om te onderzoeken.
+10 in- en uitgangen	Te complexe API. Kandidaat op te delen in verschillende componenten.
Directe HTTP-aanroepen in component	Combineer presentatie met gegevenstoegang. Servicelaag ontbreekt.
1-2 componenten per functie	Ze doen waarschijnlijk te veel. Gebrek aan interne verdeeldheid.
+20 wereldwijde aanbieders	Te veel staats- en gecentraliseerde logica. Niet alles hoeft mondiaal te zijn.

Wereldwijde diensten — het gevaar van providedIn: 'root'

Een wereldwijde service betekent dat elk onderdeel van elke functie deze kan injecteren en gebruiken. Dat creëert onzichtbare afhankelijkheden tussen functies die onafhankelijk zouden moeten zijn.

// Servicio que DEBERÍA ser local a la feature de catalog:
@Injectable({ providedIn: 'root' })  // ← señal de problema
export class ProductFilterService { ... }

// Ahora cualquier componente de cualquier feature puede usarlo.
// Si catalog cambia su lógica de filtrado, puede romper
// algo en una feature aparentemente no relacionada.

Stap 4 — app.module.ts of app.config.ts: waar u op moet letten

In apps met modules (Angular <17 of ouder)

@NgModule({
  imports: [
    BrowserModule,
    HttpClientModule,
    RouterModule,
    AuthModule,       // ← bien, infraestructura singleton

    ProductModule,    // ← señal de problema
    CartModule,       // ← señal de problema
    CheckoutModule,   // ← señal de problema
    UserModule,       // ← señal de problema
    DashboardModule,  // ← señal de problema
    // Si hay 15+ módulos de features aquí,
    // el lazy loading no está funcionando.
  ],
  providers: [
    ProductService,   // ← si hay 20+ providers aquí,
    CartService,      // hay demasiada centralización
    UserService,
    AuthService,
  ]
})

Featuremodules moeten lui (op aanvraag) worden geladen en niet rechtstreeks in de rootmodule worden geïmporteerd. Als ze er allemaal zijn, worden ze allemaal geladen bij het opstarten, zelfs als de gebruiker ze nooit nodig heeft.

In zelfstandige apps (Angular 17+)

// app.config.ts
export const appConfig: ApplicationConfig = {
  providers: [
    provideRouter(routes, withLazyLoading()),   // ← correcto
    provideHttpClient(withInterceptors([authInterceptor])),
    provideAnimations(),

    ProductService,   // ← esto NO debería estar aquí
    CartService,      // ← pertenece a la feature de cart
  ]
}

Algemene configuratieregel: De globale configuratie mag alleen een infrastructuur hebben die van invloed is op de hele app: router met lazyloading, HttpClient met globale interceptors, animaties, infrastructuur-singleton-services (auth, logger, error handler). Als u functieservices in de globale configuratie ziet, registreert iemand dingen globaal voor het gemak, niet voor noodzaak.

Volledige checklist — Eerste lezing van een Angular-app

Structuur

• Is de structuur georganiseerd op basis van kenmerken (bedrijfsdomein) of op basis van technische lagen?
• Kan ik een volledig object verwijderen door alleen de map ervan te verwijderen zonder iets anders aan te raken?
• Hebben de functies zakelijke domeinnamen (checkout, catalog) of technische namen (list, form, detail)?
• Zijn er mappen met vage namen: utils, helpers, common, misc, data?

shared/ en core/

• Bevat shared/ alleen UI-componenten en hulpprogramma's zonder bedrijfslogica?
• Bevat core/ alleen singleton-infrastructuur (interceptors, bewakers, auth-service)?
• Zijn er diensten met bedrijfslogica binnen shared/?
• Heeft core/ functiecomponenten of domeinservices?

Diensten en aanbieders

• Zijn de zakelijke dienstverlening binnen uw mogelijkheden of wereldwijd los?
• Zijn er meer dan 20 mondiale aanbieders?
• Importeert de rootmodule of app.config.ts featuremodules rechtstreeks (zonder lui)?
• Zijn er services met providedIn: 'root' die lokaal moeten zijn voor een functie?

Namen

• Zeggen de bestandsnamen precies wat ze doen?
• Zijn er bestanden waarvan de naam op een deel van de app van toepassing kan zijn?
• Is er een bestand met de naam app.service.ts, data.service.ts of helper.service.ts?
• Weegt shared/ zwaarder dan welk afzonderlijk kenmerk dan ook?

Oefening

Zoek naar een openbaar Angular-project op GitHub. Het kan uw eigen project zijn of een open source-project. Zonder bestanden te openen, alleen maar kijkend naar de mapstructuur en namen:

1. Welk organisatiemodel gebruik je: kenmerken of technische lagen?
2. Welke namen geven je twijfels of vermoedens?
3. Waar vermoed je dat de bedrijfslogica zich bevindt?
4. Welke map heeft volgens jou de meeste mix aan verantwoordelijkheden?
5. Kunt u een element verwijderen zonder iets anders aan te raken?

Deel wat u tijdens de sessie waarneemt en we bekijken het samen zoals een senior architect zou doen.

---

Prompt: analyseer uw project met de 4 punten

Kopieer deze prompt en gebruik deze met elke AI (ChatGPT, Claude, Copilot) en geef deze door aan de mappenboom van uw project:

---

Analyseer de projectarchitectuur door deze 4 punten van Pijler 1 toe te passen en genereer een rapport.

PUNT 1 — Mappenstructuur

Analyseer apps/ en libs/ en antwoord:

• Is de organisatie op basis van kenmerken (bedrijfsdomein) of op basis van technische lagen?
• Kun je een volledig object verwijderen door alleen de map ervan te verwijderen?
• Hebben de functies domeinnamen (checkout, catalog) of technische namen (list, form, detail)?
• Zijn er mappen met vage namen: utils, helpers, common, misc, data?
• Toont de daadwerkelijke boomstructuur van mappen die u hebt gevonden.

PUNT 2 — Bestands- en mapnamen

Zoek het hele project en lijst:

• Bestanden met vage namen: data.service.ts, helper.service.ts, app.service.ts, main.component.ts, utils met services erin.
• Diensten met bedrijfslogica binnen shared/.
• Componenten of domeinservices binnen core/.
• Weegt shared/ zwaarder dan welk afzonderlijk kenmerk dan ook? Aantal bestanden.

PUNT 3 — Mondiale diensten

Zoek het hele project:

• Alle services met providedIn: 'root' — vermeldt welke dit zijn en of ze lokaal voor een functie moeten zijn.
• Telt hoeveel mondiale aanbieders er in totaal zijn.
• Identificeert wereldwijd geregistreerde zakelijke services wanneer deze binnen uw functie zouden moeten vallen.
• Zoek naar diensten in libs/services/ die duidelijk tot een specifiek domein behoren.

PUNT 4 — Algemene configuratie (app.config.ts of app.module.ts)

Zoek het rootconfiguratiebestand van elke app en analyseer:

• Wat wordt er mondiaal geregistreerd wat niet mag?
• Worden de featuremodules geladen met lazyloading of worden ze rechtstreeks geïmporteerd?
• Zijn er zakelijke services in de globale configuratie?
• Hoeveel aanbieders zijn er in totaal wereldwijd geregistreerd?

RAPPORTFORMAAT

Gebruik voor elk punt deze exacte structuur:

✅ Wat is goed

(concrete lijst met echte codevoorbeelden)

⚠️ Borden om te controleren

(concrete lijst met bestandspad en waarom dit een teken is)

❌ Problemen oplossen

(concrete lijst met bestandspad, probleem en daadwerkelijke impact)

Uiteindelijk omvat het:

Samenvatting

Een tabel met de 4 punten, een status emoji (✅ ⚠️ ❌) en een conclusielijn per punt.

Prioriteit gegeven aan volgende stappen

Lijst met maximaal 5 specifieke acties, gerangschikt op impact, met het exacte pad van het bestand of de map die moet worden aangeraakt.

Wees direct. Leg niet uit wat een kenmerk of theorie is. Analyseer gewoon dit specifieke project en geef echte bevindingen.