Des calques aux fonctionnalités : pourquoi la tranche verticale est-elle née ? (Des Calques Aux Fonctionnalites Pourquoi La Tranche Verticale Est Elle Nee)

Ne blâmons pas CRUD et les couches en premier

L'architecture en couches est un bon début pour de nombreux systèmes de petite et moyenne taille. Séparation du contrôleur, du service applicatif, du référentiel et de l'accès aux données ; Cela donne à l’équipe un langage technique commun. Le problème n’est pas l’existence de ces couches. Le problème est qu’une seule demande utilisateur se propage au fil du temps à toutes les couches et chaque changement se transforme en une tâche de coordination.

Un jour, une demande en apparence simple arrive : ajouter un bon de livraison à la commande.```text Controller → Request / DTO → Service → Validator → Repository → Mapping → Test doubles → Tests

## Concepts à la première mention```text
📦 Vertical Slice
Bir kullanıcı niyetini request'ten veri kaydına ve teste kadar tek sınırda tutan uçtan uca özellik birimi.

📦 Davranışın yerelliği
Bir davranışı anlamak veya değiştirmek için gereken kodun birbirine fiziksel olarak yakın olması.

📦 Temporal DRY
Bugün benzer görünen kodun, yarın aynı sebeple değişip değişmeyeceğini sorgulayan DRY yaklaşımı.

📦 Wrong abstraction
Sadece tekrar var diye erken paylaşılan; zamanla farklı ihtiyaçları birbirine bağlayan soyutlama.
```Vertical Slice n’interdit pas les calques. Conserve la distinction technique au sein de la fonctionnalité ; La limite extérieure de la fonctionnalité est déterminée par l'intention de l'utilisateur, les règles métier et la propriété.

## Story : quand les calques ralentissent-ils ?

Le premier jour `CreateOrder` est plus petit. Un contrôleur, un service et un référentiel semblent suffisants. Ensuite, le contrôle des stocks, la règle de campagne, la préférence de livraison et l'enregistrement d'audit sont ajoutés. Lorsque chaque attribut appartient au même `OrderService`, le fichier le plus risqué du système devient le fichier le plus utilisé.```text
Yeni özellik
  → ortak Service'e dokunur
  → ilgisiz testleri etkiler
  → farklı ekiplerin release'ini bekler
```CRUD n'est pas cassé. La responsabilité du modèle et de la couche application varie. La question de Vertical Slice est la suivante : quelle intention commerciale modifie ce comportement ?

## Organisation horizontale et verticale

| Critère | Focalisé sur la couche | Axé sur les fonctionnalités |
| --- | --- | --- |
| Axe organisationnel | Rôle technique | Intention/fonctionnalité de l'utilisateur |
| Unité d'échange | Fichier sur plusieurs calques | Limite de fonctionnalité unique |
| Partage de codes | Première tendance des services communs | Partenariat éprouvé |
| Navigation | Contrôleur → service → référentiel | Fonctionnalité → requête → gestionnaire → test |
| Effet d'erreur | Peut se propager à travers une couche commune | L'élément reste plus visible à sa bordure |```text
❌ Controllers / Services / Repositories
    → OrdersController
    → OrderService
    → OrderRepository

✓ Features / Orders / CreateOrder
    → Request
    → Validator
    → Handler
    → Response
    → Tests
```Cette différence ne concerne pas seulement le nom du dossier. Cela affecte le coût de recherche, de compréhension, de test et d’annulation d’une modification. Même si le coût de recherche au sein d'une fonctionnalité reste O(n) dans le pire des cas pour le nombre de fichiers `n`, la colocalisation du code associé réduit la recherche dans les mauvais répertoires et le nombre de commutateurs mentaux.

## Screaming Architecture : que doit dire la structure des répertoires ?

Si les premiers dossiers qui apparaissent à l'ouverture d'un projet sont `Controllers`, `Services` et `Infrastructure` ; Explique les outils techniques du système. `Orders`, `Catalog`, `Billing` et `Returns` décrivent le domaine d'activité. Il doit exprimer l'intention du produit, et non le cadre architectural.

Dans un changement `CancelOrder`, le développeur trouve le gestionnaire, la vérification, la réponse et les tests du comportement au même endroit ; Cela raccourcit également la courbe d’apprentissage d’un nouveau membre de l’équipe. Cependant, le dossier des fonctionnalités n’est pas un petit monolithe où tout est public. Le point d'entrée reste ouvert ; les détails sont masqués dans la fonctionnalité.

## Cohésion, encapsulation et duplication stratégique

Une Slice ne doit pas connaître l’implémentation interne d’une autre Slice. Le comportement commun doit être partagé s'il est réellement stable et change pour la même raison par au moins plusieurs besoins indépendants. Sinon, le dossier `Shared` devient un nouveau calque sans bordures visibles.```text
CreateOrder
  → Order aggregate'e komut verir
  → local transaction'ı tamamlar
  → response üretir

CancelOrder
  → kendi kurallarını uygular
  → CreateOrder'ın handler'ını çağırmaz
```Dans cette approche, la duplication est parfois le juste prix. Si deux morceaux de code similaires doivent changer en raison de décisions commerciales différentes, leur fusion précoce peut propager chaque modification aux fonctionnalités dépendantes de O(k) dans le futur.

## Signaux de transition

Il ne suffit pas d’avoir l’air moderne pour passer à Vertical Slice. L'investissement est rentable lorsque les signaux suivants se produisent simultanément :

1. Lorsqu’une simple demande nécessite constamment des changements à plusieurs niveaux.
2. De petits changements dans les services communs interrompent les tests de fonctionnalités sans rapport.
3. Si les tests intensifs simulés préservent le comportement mais pas l'ordre d'appel interne.
4. Si l'équipe a du mal à déterminer dans quel fichier se trouve une règle métier.
5. Si les propriétaires et les rythmes de livraison des différentes fonctionnalités sont séparés.

Ces limites ne doivent pas être laissées avec la documentation. Avec les tests architecturaux dans .NET, vous pouvez vérifier qu'une fonctionnalité ne dépend pas des détails internes d'une autre fonctionnalité. Le coût de la règle est l'analyse O(dépendance) pendant la phase de compilation ou de test ; L’avantage est que la violation apparaît avant qu’elle n’atteigne la production.

## DDD et sa relation avec CQRS

Vertical Slice organise l'application. DDD décrit où se trouvent les règles métier et le langage. CQRS, en revanche, peut séparer le flux du côté commande et du côté requête d’un cas d’utilisation. Il ne s’agit pas de concurrents, mais de différents niveaux de décisions.```text
Feature boundary  → Vertical Slice
Consistency rule  → DDD Aggregate
Read / write flow → CQRS
Deployment unit   → Modular monolith veya microservice
```La validation des limites des fonctionnalités au sein du monolithe modulaire permet d'abord de tester la revendication d'indépendance sans payer tôt le coût du microservice.

## Correspondances qui créent une fausse confiance```text
❌ Vertical Slice = klasörleri yeniden adlandırmak
✓ Kullanıcı niyeti, davranış ve sahipliği aynı sınırda tutmaktır.

❌ DRY = her benzer kodu paylaşmak
✓ Aynı nedenle değişen kodu paylaşmaktır.

❌ Handler = tüm iş kuralları
✓ Handler orkestrasyon yapar; domain kuralları uygun domain modelinde yaşar.

❌ Vertical Slice = mikroservis
✓ Önce modüler monolith içinde doğrulanabilen application boundary'dir.

❌ Shared = ücretsiz yeniden kullanım
✓ Shared, sürümleme ve koordinasyon maliyeti de getirir.

Liste de contrôle de décision

1. Ce code change-t-il en raison de la même intention de l'utilisateur ?
2. La requête, la validation, le gestionnaire, la réponse et les tests d'une fonctionnalité peuvent-ils coexister ?
3. Puis-je répondre à mes besoins sans accéder à la classe interne d'une autre fonctionnalité ?
4. Cette abstraction commune change-t-elle pour la même raison en au moins trois endroits indépendants ?
5. L'orchestration globale des règles et des applications est-elle séparée ?
6. Les limites des fonctionnalités sont-elles protégées par des tests architecturaux au sein du monolithe modulaire ?
7. L'impact des erreurs, la couverture des tests et le chemin de restauration sont-ils visibles après le changement ?

Le but n’est pas de produire plus de dossiers. L’objectif est de réduire la surface de décision et de code nécessaire pour modifier un comportement.

Ce qu'il faut retenir de cet article

1. L’architecture en couches n’est pas mauvaise ; Cependant, lorsque l’unité d’échange est dispersée entre plusieurs couches, le coût de coordination augmente.
2. Vertical Slice centre le code sur l'intention et le comportement de l'utilisateur plutôt que sur les rôles techniques.
3. La duplication stratégique peut être moins coûteuse qu’une fausse abstraction.
4. Tranche verticale ; DDD est une décision d'organisation d'application qui fonctionne en conjonction avec CQRS et le monolithe modulaire.

Le but de Vertical Slice n'est pas d'organiser les fichiers verticalement ; est de maintenir l'effet du changement à la limite de fonctionnalité correcte.

Dans la section suivante, nous examinerons le fonctionnement d'un Slice de l'intérieur avec les requêtes, la validation, le gestionnaire, le mappage et les tests.