Angular : séparer vue, état et orchestration sans sur-architecturer

Dans beaucoup d'applications Angular, le problème n'est pas Angular. Le problème, c'est le composant qui finit par tout faire.

Il affiche la vue, gère les formulaires, appelle l'API, transforme les DTO, porte des règles de comportement, recalcule l'état local, orchestre les enchaînements, gère les erreurs et pilote la navigation. Au début, ça semble efficace. Quelques mois plus tard, chaque évolution devient plus risquée qu'elle ne devrait l'être.

Angular fournit pourtant déjà de bonnes briques : composants, injection de dépendances, services, et désormais une gestion d'état locale élégante avec les signals. La question n'est donc pas de savoir s'il faut ajouter une architecture compliquée. La vraie question est plus simple : où placer chaque responsabilité pour garder un code lisible, testable et remplaçable ?

L'approche que je décris ici propose une séparation pragmatique :

• le composant garde ce qui relève vraiment d'Angular et de la vue
• une couche Business injectable porte la logique de comportement du composant
• une couche Application, optionnelle, mutualise une logique commune à plusieurs business proches
• un store local en signals porte l'état du composant
• des services gèrent les accès externes
• des adapters traduisent l'API vers un modèle plus propre côté front.

Ce n'est pas un pattern Angular officiel au sens strict. En revanche, cette stratégie assemble des idées déjà bien établies : séparation présentation / logique de comportement, Service Layer, et Ports & Adapters pour isoler le domaine front des formats externes.

Le principe de base : le composant ne doit pas devenir le centre du système

Angular donne naturellement envie de mettre beaucoup de choses dans les composants, parce que tout y converge : template, événements, formulaires, lifecycle, injection, routing, signaux. C'est pratique au début, mais coûteux à maintenir ensuite.

L'idée ici est simple : le composant ne garde que ce qui est intrinsèquement lié à Angular et à la vue.

Par exemple :

• la gestion des interactions avec la vue
• le branchement avec le template
• les formulaires Angular
• les événements UI
• éventuellement des détails de cycle de vie ou de routing très proches de l'écran.

Tout le reste sort.

Autrement dit : le composant Angular reste un adaptateur de framework. Il n'est plus l'endroit où l'on "fait tourner le produit".

Une structure simple et répétable

Pour rendre cette séparation praticable à l'échelle d'un projet, il faut une convention de nommage et de branchement claire.

Un écran peut par exemple ressembler à ça :

login/
  login.component.ts
  login.component.html
  login.business.ts
  login.store.ts
  login.types.ts

Et si plusieurs écrans proches partagent une logique d'usage :

auth/
  applications/
    auth.application.ts
  services/
    auth-api.service.ts
  adapters/
    auth.adapter.ts
  models/
    auth-user.model.ts
    auth.dto.ts

L'objectif n'est pas d'imposer un arbre parfait. L'objectif est que l'équipe sache immédiatement où chercher :

• le comportement d'écran
• l'état local
• les appels externes
• les transformations de données
• la logique mutualisée entre plusieurs écrans.

La couche Business : le vrai cerveau du composant

Dans cette approche, chaque composant un peu significatif peut déléguer sa logique à une classe injectable nommée selon le composant, par exemple :

• my-component.ts
• my-component.business.ts
• MyComponentBusiness

C'est cette couche qui porte la logique de comportement de l'écran.

Elle sait par exemple :

• quoi faire quand l'utilisateur soumet un formulaire
• comment enchaîner validation, appel réseau, mise à jour d'état et navigation
• quelles données exposer au composant
• quels messages d'erreur ou états dérivés doivent être calculés
• quelles actions sont permises selon le contexte.

Il faut être précis sur le vocabulaire. Ta couche Business n'est pas forcément la "logique métier pure" au sens DDD strict. Elle mélange souvent :

• de la logique de cas d'usage locale à l'écran
• de la coordination
• des règles de comportement liées à l'UI
• parfois une partie de la logique métier côté front.

Ce n'est pas grave. Le vrai critère, ce n'est pas la pureté théorique. C'est la clarté de responsabilité.

Si cette couche rend le composant plus fin, plus testable et plus stable, elle fait déjà une grande partie du travail.

Que doit exposer une Business, au minimum ?

Très vite, une question pratique apparaît : qu'est-ce qu'une Business doit exposer au minimum ?

Une convention utile consiste à imposer un petit contrat commun. Pas pour rigidifier l'architecture, mais pour rendre toutes les Business lisibles de la même manière.

Par exemple :

import { Signal } from '@angular/core'
 
export interface BusinessLayer<TState> {
  readonly state: Signal<TState>
}

C'est volontairement minimal.

Cette interface dit une chose simple : une Business expose toujours un état lisible par le composant, sans exposer sa provenance.

Selon ton niveau d'exigence, tu peux enrichir légèrement cette base :

import { Signal } from '@angular/core'
 
export interface BusinessLayer<TState> {
  readonly state: Signal<TState>
  init?(): void
  destroy?(): void
}

Je conseille de rester sobre. Dès qu'une interface commune embarque trop de méthodes abstraites, elle finit par imposer une fausse homogénéité entre des écrans qui n'ont pas les mêmes besoins.

Définir le state du composant explicitement

Un store en signals devient beaucoup plus utile si son état est typé et nommé explicitement.

Exemple simple pour un écran de login :

export interface LoginState {
  email: string
  password: string
  loading: boolean
  submitted: boolean
  errorMessage: string | null
}

Rien d'exotique ici. Le point important, c'est d'éviter les états implicites dispersés entre plusieurs propriétés du composant.

Un écran = un état principal, même si cet état est ensuite découpé en signaux dérivés.

Le store local : état privé, lecture publique, écriture contrôlée

Le store porte l'état local du composant. Il ne doit pas être un simple objet "où on met des signaux". Il doit protéger les écritures.

Voici un exemple concret :

import { Injectable, Signal, computed, signal } from '@angular/core'
import { LoginState } from './login.types'
 
const initialState: LoginState = {
  email: '',
  password: '',
  loading: false,
  submitted: false,
  errorMessage: null
}
 
@Injectable()
export class LoginStore {
  private readonly _state = signal<LoginState>(initialState)
 
  readonly state: Signal<LoginState> = this._state.asReadonly()
 
  readonly email = computed(() => this._state().email)
  readonly password = computed(() => this._state().password)
  readonly loading = computed(() => this._state().loading)
  readonly submitted = computed(() => this._state().submitted)
  readonly errorMessage = computed(() => this._state().errorMessage)
 
  setEmail(email: string): void {
    const normalizedEmail = email.trim().toLowerCase()
 
    this._state.update((state) => ({
      ...state,
      email: normalizedEmail
    }))
  }
 
  setPassword(password: string): void {
    this._state.update((state) => ({
      ...state,
      password
    }))
  }
 
  setLoading(loading: boolean): void {
    this._state.update((state) => ({
      ...state,
      loading
    }))
  }
 
  markSubmitted(): void {
    this._state.update((state) => ({
      ...state,
      submitted: true
    }))
  }
 
  setError(message: string | null): void {
    this._state.update((state) => ({
      ...state,
      errorMessage: message
    }))
  }
 
  reset(): void {
    this._state.set(initialState)
  }
}

Ce store fait trois choses utiles :

• il encapsule l'état
• il expose des signaux de lecture
• il garde un point d'entrée clair pour les écritures.

C'est souvent suffisant pour éviter que le composant ne commence à manipuler l'état en direct.

Exemple de couche Business avec contrat minimal

La Business orchestre le comportement de l'écran à partir du store et des dépendances nécessaires.

import { Injectable, Signal } from '@angular/core'
import { firstValueFrom } from 'rxjs'
import { BusinessLayer } from '@/shared/business-layer'
import { LoginStore } from './login.store'
import { LoginState } from './login.types'
import { AuthApplication } from '../auth/applications/auth.application'
 
@Injectable()
export class LoginBusiness implements BusinessLayer<LoginState> {
  readonly state: Signal<LoginState>
 
  constructor(
    private readonly store: LoginStore,
    private readonly authApplication: AuthApplication
  ) {
    this.state = this.store.state
  }
 
  setEmail(email: string): void {
    this.store.setEmail(email)
  }
 
  setPassword(password: string): void {
    this.store.setPassword(password)
  }
 
  async submit(): Promise<boolean> {
    const { email, password } = this.state()
 
    this.store.markSubmitted()
 
    if (!email || !password) {
      this.store.setError('Le formulaire est incomplet ou invalide.')
      return false
    }
 
    this.store.setLoading(true)
    this.store.setError(null)
 
    try {
      await firstValueFrom(
        this.authApplication.login({
          email,
          password
        })
      )
 
      return true
    } catch {
      this.store.setError('Impossible de se connecter pour le moment.')
      return false
    } finally {
      this.store.setLoading(false)
    }
  }
}

Ici, la validité de saisie reste de la responsabilité du FormGroup. La Business garde seulement une garde défensive minimale avant l'appel applicatif.

Autrement dit :

• le formulaire Angular valide les champs
• le store porte l'état d'écran
• la Business orchestre le comportement.

Ça évite une double source de vérité entre validators Angular et état local.

Injection de dépendances dans un composant standalone

Le branchement avec un composant standalone doit rester simple.

Exemple :

import { ChangeDetectionStrategy, Component, inject } from '@angular/core'
import { ReactiveFormsModule, FormBuilder, Validators } from '@angular/forms'
import { Router } from '@angular/router'
import { LoginBusiness } from './login.business'
import { LoginStore } from './login.store'
import { AuthApplication } from '../auth/applications/auth.application'
import { AuthApiService } from '../auth/services/auth-api.service'
import { AuthAdapter } from '../auth/adapters/auth.adapter'
 
@Component({
  selector: 'app-login',
  standalone: true,
  imports: [ReactiveFormsModule],
  templateUrl: './login.component.html',
  changeDetection: ChangeDetectionStrategy.OnPush,
  providers: [
    LoginStore,
    LoginBusiness,
    AuthApplication,
    AuthApiService,
    AuthAdapter
  ]
})
export class LoginComponent {
  private readonly fb = inject(FormBuilder)
  private readonly router = inject(Router)
 
  readonly business = inject(LoginBusiness)
 
  readonly form = this.fb.nonNullable.group({
    email: ['', [Validators.required, Validators.email]],
    password: ['', [Validators.required, Validators.minLength(8)]]
  })
 
  onEmailInput(): void {
    this.business.setEmail(this.form.controls.email.getRawValue())
  }
 
  onPasswordInput(): void {
    this.business.setPassword(this.form.controls.password.getRawValue())
  }
 
  async onSubmit(): Promise<void> {
    if (this.form.invalid) {
      this.form.markAllAsTouched()
      return
    }
 
    this.business.setEmail(this.form.controls.email.getRawValue())
    this.business.setPassword(this.form.controls.password.getRawValue())
 
    const success = await this.business.submit()
 
    if (success) {
      await this.router.navigate(['/dashboard'])
    }
  }
}

Ce composant garde :

• le formulaire Angular
• les interactions template
• la navigation Angular
• le branchement avec la Business.

Il ne garde pas :

• l'orchestration du comportement
• l'appel applicatif
• la gestion de l'état local.

Point important : la validité du formulaire reste portée par Angular. La Business n'essaie pas de devenir un second moteur de validation.

Exemple de template : la vue passe toujours par le composant

Le template ne parle pas directement à la Business. Il parle au composant.

<form [formGroup]="form" (ngSubmit)="onSubmit()">
  <label for="email">Email</label>
  <input
    id="email"
    type="email"
    formControlName="email"
    (input)="onEmailInput()"
  />
 
  <label for="password">Mot de passe</label>
  <input
    id="password"
    type="password"
    formControlName="password"
    (input)="onPasswordInput()"
  />
 
  @if (business.state().submitted && form.controls.email.invalid) {
    <p>Email invalide.</p>
  }
 
  @if (business.state().submitted && form.controls.password.invalid) {
    <p>Le mot de passe doit contenir au moins 8 caractères.</p>
  }
 
  @if (business.state().errorMessage) {
    <p>{{ business.state().errorMessage }}</p>
  }
 
  <button type="submit" [disabled]="form.invalid || business.state().loading">
    @if (business.state().loading) {
      Connexion...
    } @else {
      Se connecter
    }
  </button>
</form>

Tu peux aussi exposer des signaux dérivés depuis la Business pour éviter de lire tout le state dans le template :

readonly loading = computed(() => this.state().loading)
readonly errorMessage = computed(() => this.state().errorMessage)

Puis côté composant :

readonly loading = this.business.loading
readonly errorMessage = this.business.errorMessage

C'est souvent plus lisible sur les écrans un peu riches.

La couche Application : mutualiser un vrai cas d'usage

La couche Application devient utile quand plusieurs Business doivent partager la même orchestration.

Exemple simple avec LoginBusiness et SignUpBusiness.

import { Injectable, inject } from '@angular/core'
import { Observable, map } from 'rxjs'
import { AuthApiService } from '../services/auth-api.service'
import { AuthAdapter } from '../adapters/auth.adapter'
import { AuthUser } from '../models/auth-user.model'
 
export interface LoginCommand {
  email: string
  password: string
}
 
@Injectable()
export class AuthApplication {
  private readonly authApi = inject(AuthApiService)
  private readonly authAdapter = inject(AuthAdapter)
 
  login(command: LoginCommand): Observable<AuthUser> {
    return this.authApi.login(command).pipe(
      map((dto) => this.authAdapter.fromLoginResponse(dto))
    )
  }
}

Ici, la Business ne connaît ni le format brut renvoyé par l'API, ni le détail de transformation du modèle. Elle orchestre un cas d'usage, point.

C'est exactement ce qu'on cherche : une réutilisation sans couplage parasite.

Le service d'accès API : parler HTTP, pas piloter l'écran

Le service parle à l'extérieur. Il ne doit pas commencer à gérer la logique d'écran.

import { Injectable, inject } from '@angular/core'
import { HttpClient } from '@angular/common/http'
import { Observable } from 'rxjs'
import { LoginCommand } from '../applications/auth.application'
import { LoginResponseDto } from '../models/auth.dto'
 
@Injectable()
export class AuthApiService {
  private readonly http = inject(HttpClient)
 
  login(payload: LoginCommand): Observable<LoginResponseDto> {
    return this.http.post<LoginResponseDto>('/api/auth/login', payload)
  }
}

Le rôle est net :

• parler HTTP
• retourner un format externe
• laisser les couches supérieures décider quoi en faire.

L'adapter : protéger le front du modèle API

Sans adapter, les DTO finissent partout. Avec un adapter, la frontière devient explicite.

import { Injectable } from '@angular/core'
import { LoginResponseDto } from '../models/auth.dto'
import { AuthUser } from '../models/auth-user.model'
 
@Injectable()
export class AuthAdapter {
  fromLoginResponse(dto: LoginResponseDto): AuthUser {
    return {
      id: dto.user_id,
      email: dto.email_address,
      displayName: dto.display_name ?? dto.email_address,
      token: dto.access_token
    }
  }
}

Exemple de DTO brut :

export interface LoginResponseDto {
  user_id: string
  email_address: string
  display_name: string | null
  access_token: string
}

Exemple de modèle côté front :

export interface AuthUser {
  id: string
  email: string
  displayName: string
  token: string
}

Le gain est immédiat :

• le front parle son propre langage
• un changement de contrat backend ne fuit pas dans toute l'UI
• la transformation est testable isolément.

Variante : exposer un contrat métier plus riche pour la Business

Si tu veux aller un cran plus loin, tu peux typer plus précisément l'API publique de la Business.

import { Signal } from '@angular/core'
import { LoginState } from './login.types'
 
export interface LoginBusinessContract {
  readonly state: Signal<LoginState>
  setEmail(email: string): void
  setPassword(password: string): void
  submit(): Promise<boolean>
}

Puis faire implémenter ce contrat :

@Injectable()
export class LoginBusiness implements LoginBusinessContract {
  // ...
}

Cette variante est utile quand :

• tu veux documenter explicitement les capacités de la Business
• tu veux découpler le composant d'une implémentation concrète
• tu veux faciliter certains tests par substitution.

En revanche, il ne faut pas créer une interface spécifique pour chaque classe sans raison. Le contrat doit apporter une vraie lisibilité, pas juste du bruit.

Exemple de test unitaire du store

L'un des intérêts de ce découpage, c'est que chaque couche devient plus facile à tester.

import { LoginStore } from './login.store'
 
describe('LoginStore', () => {
  let store: LoginStore
 
  beforeEach(() => {
    store = new LoginStore()
  })
 
  it('normalise l’email', () => {
    store.setEmail('TEST@EXAMPLE.COM ')
 
    expect(store.email()).toBe('test@example.com')
  })
 
  it('réinitialise l’état', () => {
    store.setEmail('john@doe.dev')
    store.setPassword('12345678')
    store.setLoading(true)
    store.reset()
 
    expect(store.state()).toEqual({
      email: '',
      password: '',
      loading: false,
      submitted: false,
      errorMessage: null
    })
  })
})

Exemple de test unitaire de la Business

La Business se teste aussi bien mieux quand elle ne dépend pas du composant.

import { signal } from '@angular/core'
import { LoginBusiness } from './login.business'
import { LoginStore } from './login.store'
import { AuthApplication } from '../auth/applications/auth.application'
import { of } from 'rxjs'
 
describe('LoginBusiness', () => {
  it('retourne false si le formulaire est invalide', async () => {
    const store = {
      state: signal({
        email: '',
        password: '',
        loading: false,
        submitted: false,
        errorMessage: null
      }).asReadonly(),
      markSubmitted: jasmine.createSpy(),
      setError: jasmine.createSpy(),
      setLoading: jasmine.createSpy()
    } as unknown as LoginStore
 
    const authApplication = {
      login: jasmine.createSpy()
    } as unknown as AuthApplication
 
    const business = new LoginBusiness(store, authApplication)
    const result = await business.submit()
 
    expect(result).toBe(false)
    expect(store.markSubmitted).toHaveBeenCalled()
    expect(authApplication.login).not.toHaveBeenCalled()
  })
 
  it('retourne true si la connexion réussit', async () => {
    const store = {
      state: signal({
        email: 'john@doe.dev',
        password: '12345678',
        loading: false,
        submitted: false,
        errorMessage: null
      }).asReadonly(),
      markSubmitted: jasmine.createSpy(),
      setError: jasmine.createSpy(),
      setLoading: jasmine.createSpy()
    } as unknown as LoginStore
 
    const authApplication = {
      login: jasmine.createSpy().and.returnValue(of({ id: '1' }))
    } as unknown as AuthApplication
 
    const business = new LoginBusiness(store, authApplication)
    const result = await business.submit()
 
    expect(result).toBe(true)
    expect(authApplication.login).toHaveBeenCalled()
  })
})

Sur un article pédagogique comme celui-ci, je trouve l'injection par constructeur plus lisible dans la Business. Elle reste parfaitement compatible avec Angular, et elle simplifie les tests unitaires.

C'est d'ailleurs le choix utilisé dans l'exemple LoginBusiness ci-dessus.

Où mettre quoi au quotidien

Quand un nouveau morceau de code apparaît, voici une grille de décision simple.

Dans le composant

• création du FormGroup
• gestion des événements template
• détails Angular liés à la navigation, au router, au lifecycle
• composition finale pour la vue

Dans la Business

• orchestration du comportement de l'écran
• enchaînement validation / appel / mise à jour d'état
• exposition du state vers le composant
• décisions de comportement local à l'écran

Dans l'Application

• cas d'usage partagé par plusieurs Business proches
• orchestration réutilisable
• mutualisation autour d'un sous-domaine front

Dans le store

• état local
• signaux dérivés
• setters et guards
• invariants de cohérence locale

Dans le service

• appels HTTP
• accès à des ressources externes
• détails techniques de communication

Dans l'adapter

• mapping DTO vers modèle front
• transformation de structures externes
• isolement du vocabulaire backend

Un exemple réel dans une démo Angular

J'ai aussi appliqué cette séparation dans une petite application Angular de démonstration publiée ici :

github.com/Axons-dev/axons-hateoas/tree/main/apps/angular-demo

Elle se trouve dans le dépôt Axons HATEOAS, parce qu'elle sert aussi de front de démonstration aux packages HATEOAS présentés dans l'article REST jusqu'au bout : à quoi sert vraiment HATEOAS sur une API métier ?. Mais dans le contexte de cet article, le point intéressant est surtout l'organisation du code Angular.

On y retrouve le même découpage que celui décrit ici :

case-detail/
  case-detail.component.ts
  case-detail.component.html
  case-detail.business.ts
  case-detail.store.ts

Le composant garde les responsabilités Angular : lecture des paramètres de route, réaction aux événements de la vue, branchement du template.

La Business orchestre le comportement de l'écran : chargement, action utilisateur, mise à jour de l'état, gestion d'erreur.

Le store porte l'état local de l'écran et expose une lecture stable au composant.

La démo contient aussi une partie sociale, avec liste de posts, détail de post et commentaires. Ce sont de bons exemples pour voir ce que donne ce découpage sur des écrans un peu plus vivants qu'un formulaire de login, sans transformer le composant en point de passage de toute la logique.

Les bénéfices concrets en équipe

Sur le terrain, ce type d'organisation apporte surtout quatre gains.

Des composants plus lisibles

On relit plus vite un composant qui ne contient que du code Angular et quelques délégations bien nommées.

Des tests plus ciblés

La logique utile est dans la Business, le mapping dans l'adapter, l'état dans le store. Chaque couche se teste plus simplement.

Une meilleure réutilisation de logique

Quand deux écrans proches divergent un peu, la couche Application permet de mutualiser proprement sans créer un composant abstrait ou un service fourre-tout.

Une frontière plus propre avec le backend

Les adapters protègent le front contre les variations de contrat externes et évitent que le modèle API devienne le modèle UI.

Les limites à connaître

Cette stratégie a aussi ses risques.

Le premier, c'est la surcouche. Si chaque composant, même trivial, a son business, son application, son store, son adapter et trois interfaces, on finit avec une architecture plus lourde que le problème.

Le second, c'est le flou sémantique. Si "Business" veut parfois dire logique d'écran, parfois logique métier pure, parfois orchestration technique, l'équipe perd vite son repère. Il faut donc documenter clairement ce que contient cette couche et ce qu'elle ne contient pas.

Le troisième, c'est l'anémie par déplacement. On peut très bien sortir le code des composants… et simplement déplacer le désordre dans des classes Business énormes.

Ce que cette stratégie emprunte aux patterns existants

Ta logique ne sort pas de nulle part. Elle ressemble à un assemblage pragmatique de plusieurs idées connues :

• Separated Presentation : garder la logique de présentation hors de la vue.
• Presentation Model / MVVM : sortir l'état et le comportement de la vue dans une classe dédiée.
• Presentation / Domain / Data layering : séparer présentation, logique métier et accès aux données.
• Service Layer : exposer des opérations applicatives et coordonner leur exécution.
• Gateway / Anti-Corruption Layer : traduire un modèle externe vers un modèle interne plus propre.

Donc non, ce n'est pas "la méthode officielle Angular". Mais oui, c'est une construction crédible, cohérente, et assez saine si elle reste pilotée par les vrais besoins de maintenance.

Conclusion

Dans une application Angular moderne, séparer les responsabilités ne consiste pas seulement à "mettre la logique dans des services". C'est encore trop flou.

Une stratégie plus robuste consiste à distinguer clairement :

• la vue et Angular dans le composant
• la logique de comportement d'écran dans une couche Business
• la mutualisation de cas d'usage dans une couche Application optionnelle
• l'état local encapsulé dans un store en signals
• les accès externes dans des services
• la traduction des contrats externes dans des adapters.

Ce découpage a une vertu simple : il réduit le rayon d'explosion d'un changement. Quand un écran évolue, on touche moins de couches. Quand l'API bouge, on évite de contaminer toute l'interface. Quand la logique métier grossit, elle ne fait pas exploser le composant.

Et surtout, il devient plus facile de répondre à une question très concrète, celle qui compte vraiment quand un projet grandit :

où ce code doit-il vivre pour rester compréhensible dans six mois ?

Un besoin Angular ?

Si vous cherchez un accompagnement plus opérationnel sur une application Angular existante, j'interviens aussi comme freelance Angular à Lyon.