Monolithe modulaire, ou la frontière qu'on trace avant le réseauModular monolith, or the boundary you draw before the network

Un seul déployable, aucune frontière dedans. Où passe la vraie couture ?One deployable, no boundary inside. Where does the real seam run?

L'application tient en un seul processus — c'est sain, on n'a pas besoin de plus. Mais à l'intérieur, « commandes », « facturation » et « stock » ne sont que des dossiers : chacun lit et écrit les tables des autres en direct. Il n'y a pas de module, il y a une grande base où tout le monde tape partout. Ce qui varie, ce n'est pas le nombre de serveurs : c'est l'endroit où passent les frontières entre domaines. Le réflexe : tracer ces frontières en logique — chaque module possède ses données et n'expose qu'une API — avant de songer à les tracer en réseau. La frontière logique d'abord ; le déploiement séparé, peut-être, plus tard.The app fits in one process — that's healthy, you need no more. But inside, 'orders', 'billing' and 'inventory' are just folders: each reads and writes the others' tables directly. There is no module, there's one big database where everyone reaches everywhere. What varies isn't the number of servers: it's where the boundaries between domains run. The reflex: draw those boundaries in logic — each module owns its data and exposes only an API — before thinking of drawing them over the network. The logical boundary first; separate deployment, maybe, later.

# un seul déployable, et chaque module lit les tables des autres directement
# module "commandes"
def place_order(cart):
    user = db.query("SELECT * FROM auth_users WHERE id = ?", cart.user_id)   # 💥 table d'un autre module
    price = db.query("SELECT amount FROM billing_invoices WHERE ...")        # 💥 idem
    db.execute("UPDATE inventory_stock SET qty = qty - 1 WHERE ...")         # 💥 et il écrit dedans
    db.execute("INSERT INTO orders ...")

# il n'y a pas de "module" : il y a UNE base, et tout le monde tape partout.
# "facturation", "stock", "commandes" sont des dossiers, pas des frontières.
# changer le schéma de billing_invoices casse un code qu'on ne soupçonne pas.

Tout touche à tout, et plus rien ne s'extrait.Everything touches everything, and nothing extracts anymore.

Un monolithe sans frontières internes a trois coûts qui se renforcent. Le couplage devient invisible : « facturation » lit la table de « commandes », un script lit celle de « stock », et personne ne sait plus qui dépend de quoi. Le schéma se fige : changer une colonne de billing_invoices peut casser cinq endroits dans trois domaines, alors on n'ose plus y toucher. Et l'extraction devient impossible : le jour où un module mérite vraiment son propre service, il est accroché par cinquante jointures à tout le reste — on ne peut pas le détacher sans tout démêler. La boule de boue ne se paie pas à la construction ; elle se paie quand on veut bouger.A monolith with no internal boundaries has three costs that reinforce each other. Coupling becomes invisible: 'billing' reads 'orders'' table, a script reads 'inventory''s, and no one knows who depends on what anymore. The schema freezes: changing one column of billing_invoices can break five places across three domains, so no one dares touch it. And extraction becomes impossible: the day a module truly deserves its own service, it's hooked by fifty joins to everything else — you can't detach it without untangling it all. The ball of mud isn't paid for at build time; it's paid when you want to move.

# on renomme billing_invoices.amount → amount_cents (un détail, croit-on)
# … et on découvre, en prod, qui lisait la table en douce :
commandes/checkout.py:  SELECT amount FROM billing_invoices   # 💥 cassé
stock/report.py:        JOIN billing_invoices ON ... amount     # 💥 cassé
analytics/daily.sql:    SUM(amount) FROM billing_invoices       # 💥 cassé, vu en retard
# le module "facturation" ne possédait pas ses données : tout le monde les lisait.

On trace la couture en logique, avant de songer au réseau.Draw the seam in logic, before thinking of the network.

Le monolithe modulaire trace les frontières là où passent les vraies coutures métier, sans rien déployer de plus. L'animation part de la boule de boue où trois domaines se lisent mutuellement les tables, encadre chaque domaine d'une frontière logique, donne à chacun la propriété de ses données derrière une API, puis montre l'enjeu : parce que la couture logique était la bonne, un module peut un jour passer derrière le réseau sans qu'on démêle quoi que ce soit. La frontière logique d'abord ; la frontière réseau, peut-être, et seulement si la douleur l'exige.The modular monolith draws boundaries where the real business seams run, without deploying anything more. The animation starts from the ball of mud where three domains read each other's tables, frames each domain with a logical boundary, gives each ownership of its data behind an API, then shows the stake: because the logical seam was the right one, a module can one day go behind the network without untangling anything. The logical boundary first; the network boundary, maybe, and only if the pain demands it.

# AVANT — commandes lit la table de facturation en direct
price = db.query("SELECT amount FROM billing_invoices WHERE ...")   # couplage caché

# APRÈS — commandes passe par l'API du module facturation
price = billing.get_invoice_amount(order_id)   # un appel, en mémoire, dans le même process
# billing possède billing_invoices. personne d'autre ne la lit.
# le jour où l'on extrait billing : ce SEUL appel devient un appel réseau.

Du réseau n'a jamais créé une frontière. Le monolithe distribué.The network never created a boundary. The distributed monolith.

Le piège n'est pas le monolithe — c'est de croire que séparer les processus crée les frontières qu'on n'a pas tracées. On « passe aux microservices » avant d'avoir des modules nets : on met du HTTP entre des bouts toujours couplés, et l'un lit encore la base de l'autre, par le réseau cette fois. Résultat : le même couplage qu'avant, mais le moindre changement devient un bug distribué — timeout, retry, versions d'API, panne partielle —, et deux services qu'on doit toujours déployer ensemble. C'est le monolithe distribué : tous les coûts du réseau, aucun de ses bénéfices. La frontière réseau ne vaut que si la frontière logique existait déjà. Bascule le toggle : cherche le service qui lit la base d'un autre.The trap isn't the monolith — it's believing that separating processes creates the boundaries you never drew. You 'move to microservices' before having crisp modules: you put HTTP between still-coupled pieces, and one still reads the other's database, over the network this time. The result: the same coupling as before, but the smallest change becomes a distributed bug — timeout, retry, API versions, partial failure —, and two services you must always deploy together. That's the distributed monolith: all the costs of the network, none of its benefits. The network boundary is only worth it if the logical boundary already existed. Flip the toggle: hunt the service that reads another's database.

# frontière LOGIQUE : un process, mais chaque module est propriétaire et fermé
# module facturation — possède billing_invoices, expose une API, rien de plus
class Billing:
    def get_invoice_amount(self, order_id) -> int: ...   # le SEUL accès public
    # billing_invoices n'est lue/écrite QUE par ce module

# module commandes — demande, ne prend pas
class Orders:
    def __init__(self, billing: Billing):       # dépend de l'API, pas du schéma
        self._billing = billing
    def checkout(self, order_id):
        price = self._billing.get_invoice_amount(order_id)   # appel en mémoire
# une frontière défendable, gratuite : pas de réseau, pas de sérialisation, pas de latence.

Du réseau qu'on espère structurant, ou une frontière qu'on a tracée.A network you hope structures things, or a boundary you actually drew.

Quand le monolithe (tout court) suffitWhen the (plain) monolith is enough

Le monolithe modulaire est le bon défaut, mais la modularité a un loyer : des API internes, des contrats, une discipline à tenir. On reste avec de simples dossiers — et c'est correct — quand :The modular monolith is the right default, but modularity has rent: internal APIs, contracts, a discipline to maintain. Stay with plain folders — and that's fine — when:

• l'appli tient dans une tête : un CRUD que deux personnes maintiennent n'a aucune couture métier à protéger. Y poser trois modules avec adaptateurs, c'est de la cérémonie (YAGNI, Vol 0 #3) qui paie une indirection sans douleur à soulager (Vol 0 #2).the app fits in one head: a CRUD two people maintain has no business seam to protect. Laying three modules with adapters on it is ceremony (YAGNI, Vol 0 #3) paying for indirection with no pain to relieve (Vol 0 #2).
• aucune couture ne se détache encore : tant que les domaines changent ensemble et pour les mêmes raisons, la frontière serait arbitraire. Attends la première vraie tension — deux domaines qui évoluent à des rythmes différents — pour tracer la ligne là où elle veut naturellement passer.no seam stands out yet: as long as domains change together and for the same reasons, the boundary would be arbitrary. Wait for the first real tension — two domains evolving at different rhythms — to draw the line where it naturally wants to run.
• il n'y a aucune raison de déployer séparément : pas d'équipe distincte, pas de charge à scaler à part, pas de techno différente. Sans cette douleur, passer au réseau n'achète rien et ne fait que distribuer le couplage.there's no reason to deploy separately: no distinct team, no load to scale apart, no different tech. Without that pain, going to the network buys nothing and merely distributes the coupling.

Le réflexe n'est donc pas « modularise tout, c'est plus propre » : c'est « existe-t-il une vraie couture métier, et une raison concrète de la défendre ? Alors un module qui possède ses données. Sinon, des dossiers honnêtes valent mieux qu'une frontière qu'on invente. »So the reflex isn't 'modularize everything, it's cleaner': it's 'is there a real business seam, and a concrete reason to defend it? Then a module that owns its data. Otherwise, honest folders beat a boundary you invent.'

Mot de l'éditeurFrom the editor

Ce numéro ouvre le Vol 6 — découper le système — par son défaut sain : la frontière logique avant la frontière réseau. La leçon n'est pas « le monolithe c'est bien, les microservices c'est mal » : c'est que la propreté tient aux frontières, pas au nombre de processus. Un monolithe aux modules nets est déjà découpé là où ça compte ; il a juste choisi de ne pas payer le réseau tant que rien ne l'exige. La couture se trace sur le sens métier (le Bounded Context), elle se défend par la propriété des données, et elle reste une option qu'on durcit plus tard — jamais un réseau qu'on ajoute en espérant qu'il crée l'ordre qu'on n'a pas mis.This issue opens Vol 6 — splitting the system — with its healthy default: the logical boundary before the network boundary. The lesson isn't 'monoliths good, microservices bad': it's that cleanliness lies in boundaries, not in the number of processes. A monolith with crisp modules is already split where it matters; it just chose not to pay for the network until something demands it. The seam is drawn on business meaning (the Bounded Context), defended by data ownership, and stays an option you harden later — never a network you add hoping it creates the order you didn't put there.

Avec le défaut posé, le #2 prend l'autre côté : les microservices, ce qu'on achète (le déploiement vraiment indépendant) et ce qu'on paie (le réseau devient le bug). Il prendra explicitement le contre-pied de la mode — on ne commence presque jamais en microservices —, et son anti-héros sera celui de ce chapitre : le monolithe distribué, ce qui arrive quand on découpe le réseau avant d'avoir découpé la logique. Tout le Vol 7, ensuite, vivra dans le monde qu'ouvre cette frontière réseau : que se passe-t-il quand l'autre côté ne répond pas — ou répond deux fois ?With the default laid down, #2 takes the other side: microservices, what you buy (truly independent deployment) and what you pay (the network becomes the bug). It will explicitly go against the fashion — you almost never start in microservices —, and its anti-hero will be this chapter's: the distributed monolith, what happens when you split the network before splitting the logic. All of Vol 7, then, will live in the world this network boundary opens: what happens when the other side doesn't answer — or answers twice?

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

• Bounded Context — le concept du Domain-Driven Design qui dit OÙ tracer la couture : autour d'un domaine cohérent où un même mot (« commande », « client ») garde un seul sens. La frontière du module suit le langage métier, pas le schéma technique — c'est lui qui transforme « découpage » en « vraie couture ».the Domain-Driven Design concept that says WHERE to draw the seam: around a coherent domain where one word ('order', 'customer') keeps a single meaning. The module's boundary follows the business language, not the technical schema — it's what turns a 'split' into a 'real seam'.
• Modular monolith — le nom propre de ce numéro : l'architecture qui assume un seul déployable tout en maintenant des modules fermés, à la propriété des données stricte. C'est la cible par défaut pour la grande majorité des systèmes — et la rampe de lancement la plus sûre vers les microservices, le jour où ils se justifient.this issue's proper name: the architecture that embraces a single deployable while maintaining closed modules with strict data ownership. It's the default target for the vast majority of systems — and the safest launch ramp toward microservices, the day they're justified.
• Distributed monolith — l'anti-pattern du chapitre 4, à connaître pour le fuir : des services déployés séparément mais toujours couplés, qui se lisent les bases et doivent changer ensemble. Tous les coûts du réseau, aucun de ses bénéfices. Le voisin qu'on nomme pour ne jamais y tomber — au cœur du prochain numéro.chapter 4's anti-pattern, to know so you flee it: services deployed separately but still coupled, reading each other's databases and forced to change together. All the network's costs, none of its benefits. The neighbor you name so you never fall into it — central to the next issue.

Le kata de décision — où passe la couture ?The decision kata — where does the seam run?

Rien à implémenter : le geste qui ancre, c'est de trancher où — et quand — tracer la frontière. Une appli, quatre candidats. Pour chacun, parie avant de dérouler : simple dossier, module fermé, ou mûr pour l'extraction ? Deux critères se croisent — la netteté de la couture (combien d'accès directs de l'extérieur ?) et la douleur concrète (une équipe, un scale, une contrainte). La dernière question est la sournoise : elle sépare « proprement séparable » de « à séparer ».Nothing to implement: the anchoring gesture is deciding where — and when — to draw the boundary. One app, four candidates. For each, bet before you scroll: plain folder, closed module, or ripe for extraction? Two criteria cross — the seam's crispness (how many direct accesses from outside?) and the concrete pain (a team, a scale need, a constraint). The last question is the sneaky one: it separates 'cleanly separable' from 'to be separated'.

# Une appli e-commerce, un seul process, cinq "dossiers" aujourd'hui.
# Pour chacun : simple dossier, module fermé (qui possède ses données),
# ou mûr pour l'extraction en service ? Le test décisif : combien d'accès
# directs à SES tables viennent de l'extérieur — et quelle douleur concrète ?

CATALOGUE : 40 requêtes SQL sur ses tables, dispersées dans tout le code
PAIEMENT  : touché seulement via pay() / refund() · 0 SQL externe · PCI, équipe dédiée
BLOG      : contenu marketing · aucune donnée partagée avec le commerce · aucune douleur
RECO      : lit catalogue + commandes en lecture seule · doit scaler ×10 en soldes