Don’t start with a monolith… when your goal is a microservices architecture. Great article by @stilkov on @martinfowler web site. Check it out: martinfowler.com/articles/do… #microservices #monotith
3
3
12
I fully agree with @simonbrown if you are not able to build a well structured monolith, why should you be able to build a well structured microservices system....
1
2
That is completely backward, and @simonbrown and I have disagreed about this for a long time :)
1
1
We have? I thought that we disagreed about monolith first vs going microservices from the start ... not a team’s lack of ability to create a decent modular codebase. 😀
1
3
Maybe I remember our discussions incorrectly, entirely possible. My point is: The whole point of microservices/self-contained Systems is that they prevent you from accidentally creating tight coupling
2
3
Isn’t the point that they exactly don’t? With all the interaction patterns and tools advertised, (often) blindly followed, people *think* they decoupled when in fact they just have different deployment units and boundaries that are just as coupled but much harder to refactor.
2
2
5
True, that’s in my list of anti-patterns as the “Decoupling Illusion”. Splitting things across the wrong boundaries will create a mess, and stricter boundaries will only make it worse

Sep 26, 2019 · 8:39 PM UTC

2
4
Do you have any talk available online on "Decoupling Illusion" and others anti-patterns ?
1
But you only get to know the shape of the bounded contexts after you had tried to tackle parts of the core problem. And even then, finding boundaries is a difficult process, and moderately well-structured monoliths seem more malleable.
1
1
3