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
Replying to @simonbrown @SebastienAndreo @educostadev @JuttaEckstein @martinfowler
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

Sep 26, 2019 · 8:12 PM UTC

2
3
Replying to @stilkov @simonbrown @SebastienAndreo @educostadev @JuttaEckstein @martinfowler
I agree 100% that a distributed monolith is much worse than a non-distributed one
1
1
2
But the early-stage separation, if done correctly, can help you prevent creating it in the first place
2
more replies
Replying to @stilkov @simonbrown @SebastienAndreo @educostadev @JuttaEckstein @martinfowler
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
2
4
more replies