This summer I had the chance to speak at our internal engineering conference, and wow, what an experience! The room was completely packed (even our CTO joined 😱), and we actually ran out of time due to the number of questions and discussions. That’s probably the best kind of problem to have.
My talk was titled “From Monolith to Modularity: How Deptrac Helped Us Break the Monolith”, and it told the story of how our team took a growing, hard-to-maintain PHP codebase and started turning it into a well-structured modular monolith, by using bounded contexts, clean architecture, and most importantly, Deptrac.
🛠 Why Deptrac?
We knew that saying we want boundaries wasn’t enough. We needed to enforce them. Deptrac became our static analysis companion, helping us define and protect two key architectural axes:
- Horizontal: ensuring that our bounded contexts (domains) stay isolated and only communicate through the shared kernel.
- Vertical: keeping clean layering inside each context, domain logic stays pure, and only adapters interact with the outside world.
We even got to the point where one of the bounded contexts was so cleanly separated, we could extract it into a standalone micro service. That would not have been possible without architectural discipline, and Deptrac helped us stay on track.
💬 The Best Part? The Questions
What surprised (and delighted) me the most was how many developers wanted to go deeper. From configuration quirks and refactoring strategies to microservice extraction, the discussion just didn’t want to end. We even had to wrap early because time ran out!
👀 What’s Next?
I’m considering turning this talk into a public talk. If you’re working with modular monoliths, domain boundaries, or you’re just looking to tame a growing codebase, I highly recommend giving Deptrac a try.
If you’re interested in seeing more about how we approached this refactoring journey (or want help with your own), feel free to reach out or drop a comment below, thanks! 🙂