In my experience, some of the very interesting conversations have been had around the coffee table ☕
Recently, I was having a casual discussion over coffee with a senior architect. The discussion was around a service re-architecture that we are planning to do to make it more flexible and extensible. I was talking about the efforts that I and the team are putting in to make it so flexible that we can integrate it with anything in the future.
He smiled and said: "Piyush, I don't think that a system is good if it is very flexible. I think it's good when it has defined proper boundaries"
To be honest, I did not understand that statement much at that moment.
He continued saying that if a system is very flexible then it can be exploited by anyone. See, a system is nothing but a logical grouping of components that are working together. Your boundaries separate the parts of the system that shouldn't know too much about each other. It results in a system of cooperating but independent bounded contexts.
I thought about it for a moment and understood what he was trying to convey.
Do you know why some of the systems end up becoming a monolith? Because they do not have explicit boundaries defined. In terms of microservices, it all starts with a small change where some service-A needs some data from service-B. It all looks pretty simple, right? After all, it’s just a dependency injection with a framework like Spring. But before we do this, we really need to evaluate if these 2 components are really supposed to talk to each other? Does our domain model allow this? These questions are important because every time we create a dependency between 2 components of the system, we need more coordination, more information flow, and more maintenance. If we keep on injecting our service objects wherever required in the system, we end up either creating a monolith or start talking about a rewrite of the service because it’s no longer maintainable after a while.
This is where domain-driven-design comes into the picture.
Your application boundaries help in keeping the system loosely coupled and changing one component will cause no impact on other components.
An agile team must be able to push against the fences of an architectural boundary but not cross it.
So next time when you are thinking about building a system, make sure to think about boundaries.
Remember that Good fences always make good neighbours 😃
Top comments (1)
Good one, would like to hear the other over a beer 😂