I'm reading Sam Newman's book — Building Microservices. This is another TIL coming from this book.

Often it's easy to imagine particular services when designing the software. The problem is in the details. We can't see the future, and we can't predict technical details which cause issues. Very often those technical limitations are the cause of changes in the design. So the questions is: how should we design Microservice architecture before implementation? Often, the best answer is: don't.

Sam Newman in his book introduces very interesting approach to this challenge. Simply implement monolith and then break it into Microservices. This way we can work on already stable software where boundaries are less likely to change. Otherwise, making bad assumptions about service boundaries may generate a lot of cost for the team.

I think, this is quite interesting and challenging approach. Also, I think this should be included in the plan of the project and the team should be informed and prepared for that. This awareness can influence the way developers are designing particular modules. Having clear module boundaries will make it easier to break monolith into smaller parts.