Last year I launched a vibe coding platform. What started as a monolith quickly became a warning sign — the codebase was growing, features were getting harder to add. Something had to change. I decided to commit to a full refactoring and split this complex domain into several microservices. In this article I will talk about how to do it correctly and why it matters.
Bounded Context
Domain-Driven Design was introduced by Eric Evans in the "blue book" — with the subheading Tackling Complexity in the Heart of Software. The book was written in 2003 but it seems timeless, and is probably the best reading every developer should grasp. It led us to one of the most controversial concepts in software development history — microservices.
From its beginning to today, there is a debate: should the codebase be a monolith or split into multiple domains and sub-domains?
From the title, it's obvious which philosophy I belong to. It's genuinely great that we have developers today advocating the monolithic approach — but here's what I noticed: even AI agents struggle to handle a big, tangled context. When everything lives in one giant codebase, agents lose track, make wrong assumptions, and produce lower quality output. Splitting into microservices isn't just good for humans anymore — it's becoming essential for AI-assisted development too. Till today, developers are still struggling to create proper boundaries for microservices.
The easiest way to grasp the technique for doing so is to get back to basics. In his book, Evans introduced several concepts that are the backbone of building microservice architecture. One of the most important is Bounded Context.
A Bounded Context is a boundary within which a particular domain model is defined and applicable. It's where a specific language is valid and understood by domain experts in that field — whether AI or humans. For example, developers handle one context and toolset, while project managers handle planning techniques. We will see how this affects our architecture later.
Why it matters:
In large systems, different parts of the business use the same terms differently. On my platform this became very real, very fast. For example:
- For Project Managers, "Project" may mean a Linear project that contains tasks.
- For Developers, "Project" can mean a React or Node.js project.
When these two meanings lived in the same codebase, confusion spread — for humans and agents alike. An agent asked to "create a project" had no way of knowing which meaning applied. To avoid this, each team needs its own bounded context with a clear model and unambiguous meaning of terms. Give agents a focused, well-defined context and they perform dramatically better. This was one of the key lessons building the platform.
When I was building the vibe coding platform and SDK, I introduced the following microservices:
- Project Planning Context — where tasks are prepared and planning activities are stored and managed by users or agents
- AI Coding Context — where coding agents develop the code and save it to version control, the same way humans do
- Project Deployment — all activities around building pipelines for deploying code built by AI agents; DevOps engineers will understand this context the most
- Version Control — while I had the option to use GitHub, I decided to build our own lightweight version control system optimized for AI agents
- Observability Context — the domain for analytics experts; collecting all events during agent coding
- Account and Billing — handling accounts, credits, and payments
- API Gateway — to handle authorization and security
- Platform UI
Having those 8 domains intermingled together makes it hard to understand and handle context — even for AI agents — and will ultimately lead to a "Big Ball of Mud," or if you prefer, "Spaghetti Code," which results in bugs and ultimately a bad user experience. Splitting your code into microservices brings several benefits and opens up new opportunities.
To close this section, I want to quote Eric Evans — the last sentence from the "blue book," which is by far the best call to action I have ever read in a book:
"With tools and technology we already have, we can build much more valuable systems than most projects today. We can write software that is a pleasure to use and a pleasure to work on; software that doesn't box us in as it grows, but creates new opportunities and continues to add value for its owners."
In the next section, we will look at how each of these bounded contexts is structured internally — using Hexagonal Architecture.
Top comments (0)