Search for a command to run...
Series
This series is about building modular monoliths that hold up under real pressure. Not textbook examples or folder-based "modules", but systems with enforced boundaries, clear ownership, and predictable change. Parts 6-10
Most Development Teams do not wake up one morning with the freedom to design a modular monolith from scratch. They inherit something. A system that grew organically. A codebase that made sense at the time. Controllers, services, repositories, a share...
There’s a point in every system’s life where architecture stops being something you reason about and starts being something you experience. It usually arrives during an incident, when logs are noisy, alerts are firing, and someone asks a deceptively ...
One of the quiet assumptions people carry into modular monoliths is that versioning only becomes a problem once you go distributed. While everything lives in one deployment, the thinking goes, you can just change things together and move on. That ass...
By the time you ask whether a modular monolith should be split, you already know the system well enough that the question feels uncomfortable. If it feels academic, you’re not ready. The moment it becomes emotionally charged, when people disagree str...
By the time you reach this point in the series, you have made a lot of architectural promises. You have said that modules are isolated, that behaviour is local, that data is owned, that communication is explicit, and that authorisation does not leak ...
