Layered, ou la couche qui en sait tropLayered, or the layer that knows too much

Trois couches, une seule question : chacune sait-elle seulement son métier ?Three layers, one question: does each one know only its own job?

C'est la première séparation que tout le monde dessine : Présentation, Métier, Données. Le découpage le plus utile et le plus ancien — et il marche, à une condition rarement dite à voix haute. La valeur n'est pas dans les trois boîtes ; elle est dans une règle de savoir : chaque couche ne connaît que sa préoccupation et ne parle qu'à celle d'en dessous. Le jour où une couche en sait trop, le découpage ne sépare plus rien.It's the first separation everyone draws: Presentation, Business, Data. The oldest, most useful split — and it works, on one condition rarely said out loud. The value isn't in the three boxes; it's in a rule of knowledge: each layer knows only its concern and talks only to the one below. The day a layer knows too much, the split separates nothing.

Présentation   →   contrôleurs, vues, sérialisation
Métier         →   règles, décisions, invariants
Données        →   requêtes, ORM, schéma

La couche métier se vide, et la règle se réfugie partout ailleurs.The business layer empties out, and the rule takes refuge everywhere else.

Le découpage en couches ne tombe pas en panne bruyamment — il se vide. Une règle simple — « 10 % de remise pour un client gold au-dessus de 100 € » — doit vivre quelque part. Sous la pression du sprint, elle se pose là où on code à l'instant : un if dans le contrôleur, un CASE dans le SQL, une condition dans le template. La couche métier, censée la porter, ne contient plus que des appels qui passent le plat.Layering doesn't fail loudly — it hollows out. A simple rule — '10% off for a gold customer above €100' — must live somewhere. Under sprint pressure it lands wherever you're coding right now: an if in the controller, a CASE in the SQL, a condition in the template. The business layer, meant to hold it, ends up with nothing but calls passing the plate.

# Présentation — le contrôleur décide
if user.tier == "gold" and cart.total > 100:   # ✗ règle métier ici
    cart.total *= 0.9

# Données — le SQL re-décide la même chose, autrement
SELECT total * CASE WHEN tier='gold' AND total>100 THEN 0.9 ELSE 1 END  # ✗

On suit une règle, et on la regarde rentrer chez elle.Follow one rule, and watch it come home.

Stratifier ne consiste pas à dessiner trois boîtes : c'est à décider, pour chaque savoir, dans quelle boîte il a le droit de vivre. La remise « gold au-dessus de 100 € » est une décision métier — donc elle appartient à la couche métier, et nulle part ailleurs. L'animation suit ce seul morceau de connaissance pendant qu'on le retire de la vue et du SQL pour le concentrer là où c'est sa place.Layering isn't drawing three boxes: it's deciding, for each piece of knowledge, which box it's allowed to live in. The 'gold above €100' discount is a business decision — so it belongs in the business layer, and nowhere else. The animation follows that one piece of knowledge as we pull it out of the view and the SQL to concentrate it where it belongs.

# Métier — le SEUL endroit qui décide d'une remise
class Cart:
    def total_due(customer) -> Money:
        if customer.is_gold and self.subtotal > 100:
            return self.subtotal * 0.9
        return self.subtotal

# Présentation : affiche total_due(), ne (re)calcule rien
# Données : persiste le sous-total brut, ne (re)décide rien

Trois couches bien dessinées — et une couche métier qui ne pense pas.Three neatly drawn layers — and a business layer that doesn't think.

Le piège n'est pas d'oublier une couche : c'est d'avoir une couche métier qui ne porte aucune décision. Les entités deviennent des sacs de getters/setters, et toute la logique part dans des « services » qui les manipulent de l'extérieur. C'est le modèle de domaine anémique (Fowler) — un anti-pattern d'autant plus dangereux qu'il ressemble à du code propre. Bascule le toggle : regarde où vit le comportement.The trap isn't forgetting a layer: it's having a business layer that carries no decision. Entities become bags of getters/setters, and all logic moves into 'services' that manipulate them from outside. That's the anemic domain model (Fowler) — an anti-pattern all the more dangerous for looking like clean code. Flip the toggle: watch where behavior lives.

# Modèle riche — le comportement vit AVEC la donnée qu'il garde
class Cart:
    def add(self, item):
        if self.is_locked: raise CartLocked()   # l'invariant est protégé ici
        self._items.append(item)

    def total_due(self, customer) -> Money:
        base = sum(i.price for i in self._items)
        return base * 0.9 if customer.is_gold and base > 100 else base

# le service orchestre, il ne décide pas :
class Checkout:
    def run(cart, customer): pay(cart.total_due(customer)); cart.lock()

La règle éparpillée sur trois étages, ou concentrée dans sa couche.The rule scattered across three floors, or concentrated in its layer.

Quand ne pas enrichir le domaineWhen not to enrich the domain

Le découpage en couches a un loyer modeste ; le domaine riche, lui, peut être un sur-coût net. On le laisse anémique — et c'est correct — quand :Layering's rent is modest; a rich domain, though, can be a net overcost. Leave it anemic — and that's fine — when:

• le domaine n'a pas de règles : un CRUD d'administration qui crée, lit, met à jour des lignes sans invariant. Une entité riche n'y protège rien — c'est de la cérémonie.the domain has no rules: an admin CRUD that creates, reads, updates rows with no invariant. A rich entity protects nothing there — it's ceremony.
• la logique est intrinsèquement transverse : un calcul qui croise dix entités n'appartient à aucune. Là, un service (un transaction script) est le bon foyer — ce n'est pas une fuite, c'est sa couche.the logic is inherently cross-cutting: a calculation spanning ten entities belongs to none. There a service (a transaction script) is the right home — it's not a leak, it's its layer.
• le découpage horizontal en couches commence lui-même à coûter : quand chaque feature traverse les trois couches et qu'on les rouvre ensemble à chaque fois, le découpage vertical par feature (Vertical Slices) répartit mieux le savoir. On le verra au Vol 2 #2.the horizontal split itself starts to cost: when every feature crosses all three layers and you reopen them together each time, a vertical, per-feature split (Vertical Slices) distributes knowledge better. We'll see it in Vol 2 #2.

Le réflexe n'est donc pas « domaine riche partout ». C'est : « cette règle a-t-elle un foyer naturel — une entité qu'elle gouverne ? Si oui, elle y vit, et les autres couches ne la connaissent pas ; sinon, elle vit dans un service, et c'est sa place, pas une fuite. »So the reflex isn't 'rich domain everywhere'. It's: 'does this rule have a natural home — an entity it governs? If yes, it lives there, and the other layers don't know it; if not, it lives in a service, and that's its place, not a leak.'

Mot de l'éditeurFrom the editor

Le découpage en couches est si banal qu'on oublie ce qu'il promet : non pas trois dossiers, mais une réponse à « qui a le droit de savoir ça ? ». Le débutant range ses fichiers par type — controllers/, services/, models/ — et croit avoir architecturé. L'architecte range le savoir par responsabilité, et vérifie qu'aucune couche n'en sait plus que son métier.Layering is so banal we forget what it promises: not three folders, but an answer to 'who is allowed to know this?'. The beginner files code by type — controllers/, services/, models/ — and thinks they've architected. The architect files knowledge by responsibility, and checks that no layer knows more than its job.

Le Vol 1 réglait le sens des flèches ; ce numéro règle la répartition du savoir — deux axes orthogonaux d'une même phrase. La suite généralise la règle de dépendance vers l'intérieur (Clean, Hexagonal) et lui oppose son contre-courant, le découpage vertical par feature. Mais la question de fond ne bougera plus : chaque morceau de code ne devrait connaître que ce dont il a la charge.Vol 1 settled the direction of arrows; this issue settles the distribution of knowledge — two orthogonal axes of the same sentence. What follows generalizes the inward dependency rule (Clean, Hexagonal) and sets it against its counter-current, the vertical per-feature split. But the underlying question won't move: each piece of code should know only what it's responsible for.

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

• MVC · MVVM · MVP — la même règle de savoir appliquée à l'interface : garder la vue passive et la décision ailleurs (contrôleur, présentateur, view-model). Trois variantes d'un seul réflexe.the same rule of knowledge applied to the UI: keep the view passive and the decision elsewhere (controller, presenter, view-model). Three variants of one reflex.
• Transaction Script vs Domain Model — les deux foyers possibles de la logique métier : une procédure par cas d'usage, ou un comportement porté par les entités. Le choix dépend de la richesse des règles, pas de la mode.the two possible homes for business logic: one procedure per use case, or behavior carried by entities. The choice depends on how rich the rules are, not on fashion.
• Anemic Domain Model — l'anti-pattern nommé par Fowler : des entités sans comportement et des services qui les pilotent de l'extérieur. Légitime en CRUD pur, piège dès qu'il y a un invariant à tenir : vider une entité de ses règles ne les supprime pas, ça les éparpille dans les services — le piège de la relocalisation du Vol 0 #4.Fowler's named anti-pattern: behavior-free entities driven from outside by services. Legitimate in pure CRUD, a trap the moment there's an invariant to hold: emptying an entity of its rules doesn't remove them, it scatters them across the services — the relocation trap of Vol 0 #4.

Le kata — écris-le, ne le relis pasThe kata — write it, don't reread it

# test_cart_rules.py — la spec EST le harnais : fais-le passer au vert.
# une entité qui garde ses invariants et loge la règle en UN endroit. sans framework.

def test_total_applique_la_remise_gold():
    cart = Cart(items=[Item(60), Item(60)])        # sous-total 120
    assert cart.total_due(gold) == 108             # -10 % au-dessus de 100
    assert cart.total_due(regular) == 120          # personne d'autre n'y a droit

def test_pas_de_remise_sous_le_seuil():
    cart = Cart(items=[Item(90)])
    assert cart.total_due(gold) == 90              # 90 < 100 : rien

def test_panier_verrouille_refuse_l_ajout():
    cart = Cart(items=[Item(10)]); cart.lock()
    with raises(CartLocked): cart.add(Item(5))     # l'invariant est tenu par l'entité

def test_l_ajout_est_le_seul_chemin_vers_l_etat():
    cart = Cart(items=[])
    assert not hasattr(cart, "items")              # pas de porte dérobée vers l'état
    # on ne peut pas contourner add() : la garde ne vit pas dans un service externe

def test_la_regle_a_un_seul_domicile():
    cart = Cart(items=[Item(200)])
    # l'export réutilise total_due, il ne la recopie pas.
    assert export_total(cart, gold) == cart.total_due(gold)   # une seule source de vérité