June 21, 2015 at 07:42PM
"If you start with a monolith, the parts will become extremely tightly coupled to each other." #readingToday  

But if you start with a monolith, the parts will become extremely tightly coupled to each other. That's the very definition of a monolith. The parts will rely on features of the platform they all use. They'll communicate based on abstractions that are shared because they all use the same libraries. They'll communicate using means that are only available when they are hosted in the same process. And these are only the technical aspects! Far worse than that, the parts will (almost) freely share domain objects, rely on the same, shared persistence model, assume database transactions are readily available so that there's no need for compensation … Even the very fact that it's easy to refactor things and move them around – all in the convenience of your IDE's view of a single project – is what makes it extremely hard to cut things apart again. It's extremely hard to split up an existing monolith into separate pieces.

Don't start with a monolith if you want to end up with microservices. It's usually a good idea to follow the YAGNI principle, but a monolith won't magically contain services waiting to be liberated.