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