Depuis quelques années, je vois passer le même conseil : "Une bonne architecture doit rester simple et adaptée au contexte. Un vrai dev ne fait pas d’over-engineering."
Puis : "Pas besoin de microservices, CQRS, Event Sourcing..."
Déjà, mettre microservices, CQRS et ES dans le même sac, c’est comparer l’urbanisme, la circulation et les archives d’une ville : même système, problèmes différents.
Mais surtout : sur quoi vous basez-vous pour déterminer le "bon niveau d’architecture" ? Sur ce que le client vous a raconté au premier atelier de 10mn ?
Un client décrit ce qu’il croit vouloir aujourd’hui, rarement ce que son logiciel devra absorber demain.
Sur mes 3 derniers projets :
- "Il nous faut juste une calculatrice" est devenu un système de pilotage des achats pour 30 M€.
- "Un Excel amélioré" est devenu un outil gérant charges, machines, compétences et turnover.
- "Le planning sera très simple" est devenu une application multisite avec des problèmes de connexion.
Si j’avais dimensionné l’architecture sur le discours initial, j’aurais fait quelque chose de "simple". Tellement simple qu’il aurait fallu tout réécrire quelques mois plus tard. 🤦♂️
Une partie du problème vient du web : on appelle "application" une page avec trois formulaires et une base derrière. Pour un site plaquette, pas besoin de sortir l’artillerie lourde. Mais une vraie application de gestion utilisée par des 10ene ou 100ene de personnes, c’est autre chose : les règles bougent et les exceptions deviennent la norme.
Je vais bientôt avoir 30 ans d’expérience dans la tech : 5 ans dans l’infra, 15 ans sur des logiciels de gestion traditionnels, bientôt 10 ans en CQRS/ES. J’ai eu le temps de voir ce qui tient dans la durée et ce qui casse à la prochaine demande métier.
Le coût d’une architecture ne se mesure pas au nombre de classes créées au démarrage, mais au prix du changement 6 mois, 3 ans ou 10 ans plus tard.
Une architecture trop simpliste produit souvent un effet cocasse : comme le logiciel supporte mal le changement, on essaie d’empêcher le client de changer d’avis. On contractualise, on fige, on ressort le fameux "Mais vous aviez dit que...".
C’est pratique : au lieu de rendre le logiciel adaptable, on essaie de rendre le client immuable.
Et non, CQRS/ES ne servent pas uniquement à l’audit ou à la traçabilité. On peut aussi les choisir parce qu’on accepte une évidence : on ne sait pas encore ce que le métier nous demandera demain.
Bref, considérer qu'une architecture ambitieuse est forcément de l’over-engineering parce que le besoin semble simple aujourd’hui, c’est juste remplacer un dogme par un autre.
C’est comme partir à la guerre sans arme en disant : "YAGNI. On fabriquera les fusils quand quelqu’un commencera à tirer. 🤓 "
Une bonne architecture n’a pas pour but de prédire l’avenir. Elle doit faire en sorte que, lorsqu’il vous donne tort, vous ne soyez pas obligé de tout réécrire.
La simplicité, oui. Le simplisme déguisé en expertise, beaucoup moins.
Plain Pattern Language: a book review on the origin of Design Patterns - Lorie den Os
Have you actually read the GoF's "Design Patterns"? Lorie den Os hasn't! Instead, she read "A Pattern Language", a 1200-page book on physical architecture that deeply inspired the Gang of Four.
Initially picking it up with the sole intention of building better houses in The Sims 🎮, she shares what she learned from it as both a developer and a linguist. A refreshing book review that gets to the heart of a fundamental question: why do we code?
#designpatternsinjava #architecture #softwareengineering #sims4 #ForkIt2026 #bookreview
A simpler and more flexible approach to consistency in event-driven systems
What is it?
Dynamic Consistency Boundaries (DCB) is a technique for enforcing consistency in event-driven systems without relying on rigid transactional boundaries.
Traditional systems use strict constraints to maintain immediate consistency, while event-driven architectures embrace eventual consistency for scalability and resilience. However, this flexibility raises challenges in defining where and how consistency should be enforced.
Introduced by Sara Pellegrini in her blog post "Killing the Aggregate", DCB provides a pragmatic approach to balancing strong consistency with flexibility. DCB allows for the selective enforcement of strong consistency where needed, particularly for operations that span multiple entities. This ensures critical business processes and cross-entity invariants remain reliable while avoiding the constraints of traditional transactional models. DCB helps teams optimize performance, scalability, and operational correctness by defining context-sensitive consistency boundaries.
Ma réaction à un commentaire (je ne l'ai pas publié).
@SirBenJamin_ 1 hour ago
In my experience, most coupling problems (and other architecture problems) are caused by teams where everyone works on all parts of the codebase, i.e people don't specialise in a particular area, they just pick up the next ticket on the backlog, and then even worse, other people who also have no experience in the area review the code. Managers will see this as a good thing, as they think they're getting more bang for their buck by 'spreading the knowledge.' ... but I really don't think it ever ends up like that, and the codebase suffers
I think "everyone works on all parts of the codebase" could not be a problem per se if the knowledge is evenly distributed. In very big systems it might not be possible and thus I agree with you that specialization could be an useful strategy. Also, you back this with your experience, so empirical evidence strenghtens your point.
In systems not so big, I think that T shape profile along with good ownership distribution (with pair programming, ensemble programming, ADRs), could also have positive effects on coupling problems. Meaning having knowledge a bit larger than hers scope could help having a glance of neigbourg culture (such as how mapping is done in the team next to me).
Techniques such as "swarming" : helping others being stuck or learning things outside of our initial scope (ex. QA, learning a bit of programming skill, Backend learning a bit of frontend ...) might help growing more shared mental models and thus slowly growing in the direction of full stack profile.
This lovely comic illustrates it pretty well I think : https://blog.crisp.se/2009/06/26/henrikkniberg/1246053060000
The Boundary-Control-Entity (BCE/ECB) pattern is a software architecture pattern that organizes code into Business Components. A Business Component is a package or namespace comprising three distinct layers, each with specific responsibilities. Business components adhere to the principles of maximal cohesion and minimal coupling, and are named after their domain responsibilities.
Par : Bastien David – Le 9 juin 2026 à Grenoble
L’architecture logicielle n’est pas seulement une affaire de schémas : elle est aussi le reflet des organisations qui la produisent. Bastien David explore l’impact des structures d’équipe sur les décisions techniques, les limites des comités d’architecture, et les formes de décentralisation qui permettent davantage d’autonomie. Un talk pour réfléchir à la manière dont on peut influencer, à son niveau, une culture d’équipe plus collaborative.
Christopher Alexander’s keynote speech at the ACM Convention on “Object Oriented Programs, Systems, Languages and Applications”, (OOPSLA) in San Jose, CA, October 6 - 10 1996. Christopher Alexander connects his architectural work on patterns and pattern languages [03:40] with the field of computing. He introduces the theoretical framework behind his upcoming work, "The Nature of Order" [04:12], and expresses concern about the lack of "living structure" in the modern built environment [05:52]. Alexander emphasizes the moral component underlying his work, questioning if computing patterns also strive to improve human life [13:39]. He discusses the importance of a pattern language's ability to generate coherent wholes [17:32], the recursive structural characteristics related to patterns [21:11], finding objective criteria for "life" in structures [24:57], and the concept of "unfolding wholeness" [41:25]. He concludes by urging the computing community to consider their potential role in creating living structures in the world [59:22].
Transcript : https://www.patternlanguage.com/archive/ieee.html
Learn to write better, resilient CSS
If you find yourself wrestling with CSS layout, it’s likely you’re making decisions for browsers they should be making themselves.
Through a series of simple, composable layouts, Every Layout will teach you how to better harness the built-in algorithms that power browsers and CSS.
In this video I analyze the DOOM project by id Software.
Comment, like, subscribe, let’s trigger the algo!
The focus will be on software architecture, technical limitations, technical concepts.
If you like the content comment, like and subscribe to support the channel!
- 00:00 DOOM
- 03:18 Software Architecture
- 08:06 Build Process
- 10:04 Component Diagram
- 11:07 WAD Files
- 13:20 Main Loop
- 14:35 2D Renderer
- 20:45 3D Renderer Intro
- 24:22 Binary Space Partitioning
- 27:45 BSP Example
- 31:03 Player FOV
- 35:22 Wall Clipping
- 40:30 Visplanes
- 41:25 "Masked"
- 42:21 Conclusion and Lessons