Vertical Slices vs Clean, ou le long de quel axe ça changeVertical Slices vs Clean, or which axis change runs along

Le même code, deux découpes. Le long de quel axe ton code change-t-il ?The same code, two cuts. Along which axis does your code change?

Le Vol 1 #2 a tranché le sens des dépendances ; le #1 de ce volume a réparti le savoir entre couches. Reste une question qu'aucun des deux ne pose : selon quel axe ranger les dossiers ? Par rôle technique — controllers/, services/, repositories/ — ou par feature — checkout/, refund/, inventory/, chacune portant sa propre tranche verticale. Ce n'est pas une querelle de goût : on optimise la découpe pour le changement qu'on fait le plus souvent.Vol 1 #2 settled the direction of dependencies; this volume's #1 distributed knowledge across layers. One question neither asks remains: along which axis do you arrange the folders? By technical role — controllers/, services/, repositories/ — or by feature — checkout/, refund/, inventory/, each carrying its own vertical slice. It's not a matter of taste: you optimize the cut for the change you make most often.

# Par couche (horizontal)        # Par feature (vertical)
controllers/                     checkout/
  checkout_controller            controller · service · repo
  refund_controller            refund/
services/                          controller · service · repo
  checkout_service             inventory/
  refund_service                 controller · service · repo
repositories/
  order_repository

Ajouter une feature touche six fichiers dans trois couches — à chaque fois.Adding a feature touches six files across three layers — every time.

Le découpage horizontal est excellent pour ce qui change rarement : remplacer Postgres, changer de framework web. Mais ce n'est presque jamais ce qui change. Ce qui change, c'est une feature : « emballer un cadeau au checkout », « rembourser partiellement ». Et une feature, dans une arborescence par couche, est éparpillée sur tous les étages. On rouvre les trois couches ensemble, toujours.Horizontal splitting is excellent for what rarely changes: replacing Postgres, swapping the web framework. But that's almost never what changes. What changes is a feature: 'gift-wrap at checkout', 'partial refund'. And a feature, in a by-layer tree, is scattered across every floor. You reopen all three layers together, always.

# feature « emballage cadeau » — le diff :
  controllers/checkout_controller   (+ champ gift_wrap)
  services/checkout_service         (+ règle de prix)
  repositories/order_repository     (+ colonne)
  dto/checkout_dto                  (+ champ)
# 4 dossiers ouverts pour 1 intention

Aucune découpe n'est gratuite : on choisit l'axe qu'on rend bon marché.No cut is free: you choose which axis you make cheap.

Voici la même application comme une grille : trois couches en lignes, trois features en colonnes. Un changement allume toujours soit une colonne (une feature, tous ses étages), soit une ligne (une techno, toutes les features). Ce qui varie, c'est le sens où l'on a tracé les dossiers. L'animation montre le même changement se localiser dans un cas et s'éparpiller dans l'autre — preuve qu'on ne gagne pas sur les deux axes.Here's the same application as a grid: three layers as rows, three features as columns. A change always lights up either a column (one feature, all its floors) or a row (one tech, all features). What varies is the direction you drew the folders. The animation shows the same change localize in one case and scatter in the other — proof you can't win on both axes.

checkout/                 # la feature possède toute sa tranche
    Endpoint.handle(req)  # entrée▸ à toiyour turn — dans une slice, où vit la règle métier de ce cas d'usage ?inside a slice, where does this use case’s business rule live? · cliquer pour révélerclick to reveal    CheckoutStore         # port + adapter, locaux à la slice
# changer le checkout = ouvrir un dossier, et un seul.
# le métier qui mérite la règle de dépendance (Vol 1 #2)▸ à toiyour turn — la règle de dépendance du Vol 1 #2 : sur toute l'appli, ou bornée à… ?Vol 1 #2’s dependency rule: across the whole app, or bounded to… ? · cliquer pour révélerclick to reveal

Découper en features n'abolit pas la règle de dépendance — ça la déplace.Cutting by feature doesn't abolish the dependency rule — it relocates it.

Le piège des slices verticales n'est pas leur idée, c'est leur mise en œuvre naïve : croire que « par feature » dispense de toute abstraction partagée. On copie alors la règle métier dans chaque slice, ou pire, une slice va fouiller dans les internes d'une autre. Le couplage horizontal qu'on fuyait revient — déguisé en indépendance. Bascule le toggle : suis la règle de remise et les imports entre slices.The vertical-slice trap isn't the idea, it's the naive build: believing 'by feature' frees you from any shared abstraction. So you copy the business rule into each slice, or worse, one slice digs into another's internals. The horizontal coupling you fled comes back — disguised as independence. Flip the toggle: follow the discount rule and the cross-slice imports.

# slices isolées ; ce qui est vraiment commun vit dans un noyau possédé
shared/pricing/                  # noyau de domaine, contrat explicite
    discount_for(customer, total) -> Money

checkout/                        # importe le noyau, n'expose rien
    ConfirmCheckout: total = discount_for(customer, subtotal)
refund/                          # importe le MÊME noyau
    IssueRefund:    amount = discount_for(customer, original)
# une slice n'atteint jamais les internes d'une autre.

Découper par couche, par feature — ou les deux, à la bonne maille.Cut by layer, by feature — or both, at the right grain.

Le contre-procès : quand Clean est un sur-coûtThe counter-trial: when Clean is overkill

La Clean / Hexagonal du Vol 1 #2 a un loyer réel — ports des deux côtés, composition root, couche de traduction. On ne le paie pas par principe. On reste plat — couches simples, voire framework direct — quand :The Clean / Hexagonal of Vol 1 #2 has real rent — ports on both sides, a composition root, a translation layer. You don't pay it on principle. Stay flat — simple layers, even framework-direct — when:

• le produit est un CRUD : la plupart des slices n'ont aucune règle. Une slice plate — endpoint → requête — est honnête ; l'hexagone n'y entourerait que du vide. On réserve la règle de dépendance aux rares slices qui portent un invariant.the product is CRUD: most slices have no rules. A flat slice — endpoint → query — is honest; the hexagon there would wrap only emptiness. Reserve the dependency rule for the rare slices carrying an invariant.
• l'équipe tient en deux personnes et le time-to-market prime : l'indirection coûte aujourd'hui et ne rapporte qu'au changement futur. C'est le YAGNI du Vol 0 #3 — tant que le point de non-retour n'est pas en vue, on garde le code simple à supprimer.the team is two people and time-to-market wins: indirection costs today and only pays on a future change. It's Vol 0 #3's YAGNI — until the point of no return is in sight, keep code easy to delete.
• le métier n'est pas encore compris : tracer des frontières sur un domaine qu'on découvre, c'est figer de mauvaises lignes. On laisse le code grumeleux jusqu'à voir l'axe de variation réel (Vol 0 #1), puis on découpe.the business isn't understood yet: drawing boundaries on a domain you're still discovering freezes the wrong lines. Keep the code lumpy until the real axis of variation shows (Vol 0 #1), then cut.

Le réflexe n'est donc ni « Clean partout » ni « slices partout ». C'est : « slices au premier niveau — l'arbo doit crier le métier — et, à l'intérieur, la règle de dépendance seulement pour les slices qui ont un vrai métier à protéger. Les autres restent plates. »So the reflex is neither 'Clean everywhere' nor 'slices everywhere'. It's: 'slices at the top level — the tree should scream the business — and inside, the dependency rule only for slices that have real business to protect. The rest stay flat.'

Mot de l'éditeurFrom the editor

On présente souvent Vertical Slices et Clean comme deux camps. Ce sont deux axes d'une même feuille de papier : Clean dit dans quel sens pointent les dépendances, Slices dit le long de quelle ligne on plie. Choisir un camp, c'est confondre l'orientation et la maille. Le débutant cherche LA bonne architecture ; l'architecte aligne chaque frontière sur l'axe selon lequel ce système-là changera.Vertical Slices and Clean are often pitched as two camps. They're two axes of the same sheet of paper: Clean says which way dependencies point, Slices says along which line you fold. Picking a camp confuses orientation with grain. The beginner hunts for THE right architecture; the architect aligns each boundary with the axis along which this particular system will change.

Deux numéros, deux réponses à la même question — qui a le droit de connaître quoi. Une couche ne doit savoir que son métier (#1), et la frontière des dossiers doit suivre l'axe du changement (#2). Mais découper en slices laisse un reste embarrassant : l'auth, le log, la validation, la trace ne sont d'aucune slice — ils les traversent toutes. Les dupliquer dans chacune, c'est signer l'oubli du jour où l'une manquera à l'appel ; les remonter dans le cœur, c'est refaire la couche qui en sait trop. Le #3 sort ce transverse du cœur sans l'éparpiller.Two issues, two answers to the same question — who has the right to know what. A layer should know only its job (#1), and folder boundaries should follow the axis of change (#2). But cutting into slices leaves an awkward remainder: auth, logging, validation, tracing belong to no slice — they cross all of them. Duplicating them in each is signing up for the day one goes missing; hoisting them into the core is rebuilding the layer that knows too much. #3 pulls that cross-cutting concern out of the core without scattering it.

Les voisins que ce numéro débloqueThe neighbors this issue unlocks

• Screaming Architecture — le test de l'arbo : les dossiers de premier niveau doivent nommer le métier (checkout, refund), pas la techno (controllers, services). Si l'arbo crie le framework, la découpe suit le mauvais axe.the tree test: top-level folders should name the business (checkout, refund), not the tech (controllers, services). If the tree screams the framework, the cut follows the wrong axis.
• Feature Folders — la forme la plus simple du découpage vertical : un dossier par cas d'usage, sans cérémonie. Le point d'entrée des slices avant d'y porter la règle de dépendance.the simplest form of vertical cutting: one folder per use case, no ceremony. The entry point to slices before carrying the dependency rule into them.
• Modular Monolith — la slice poussée jusqu'au module à frontière dure — antichambre des microservices, sans le coût réseau. On y revient quand on parlera de découpage en services.the slice pushed to a hard-boundaried module — the antechamber of microservices, without the network cost. More when we cover splitting into services.

Le kata de décision — tranche avant de déroulerThe decision kata — decide before you scroll

Pas de code à faire passer au vert ici : ce numéro est un choix d'axe, pas un mécanisme. Le kata est donc un scénario à trancher. Lis-le, engage-toi sur chaque décision — à voix haute ou par écrit — avant d'ouvrir la réponse. Se tromper avant de lire ancre mieux que lire d'abord.No code to turn green here: this issue is a choice of axis, not a mechanism. So the kata is a scenario to settle. Read it, commit to each decision — out loud or in writing — before opening the answer. Getting it wrong before reading anchors better than reading first.