8 ms·

Starting with a monolith could lead to really difficult refactorings unless you structure the code in a way that it can be easily decoupled.

by eweise 6y ago

dpix 6y ago
The same argument can be made for building separate services too. Could become very difficult to merge data between two services after you had redundant information being saved across the two because of a bad design up-front.
afarrell 6y ago
I once worked in a monolith that was structured in a way that it could have been easily decoupled. It never was because the codebase was so modular and well-tested that the only time we ever felt the need was when trying to assign ownership to runtime exceptions. https://gocardless.com/blog/getting-started-with-coach/ https://gocardless.com/blog/getting-started-with-coach/ was the framework.
- mikepurvis 6y ago
  Exception triage often requires examining the stack regardless— even if you have multiple processes, you're still going to have errors bubbling up from your pool of shared library code.
stcredzero 6y ago
Law of Demeter! That idea had a lot of influence from Smalltalk, where the natural way of developing was in a monolith. So tactics like that which are about decoupling by default were a good idea in that context. https://wiki.c2.com/?LawOfDemeter https://wiki.c2.com/?LawOfDemeter
JamesBarney 6y ago
Monolith -> microservices : difficult refactoring Microservices -> monolith : difficult refactoring Microservices with poorly chosen context boundaries -> microservices with well chosen context boundaries: very difficult refactoring.
- eweise 6y ago
  "Monolith -> microservices : difficult refactoring" I guess my point is that it doesn't have to be complicated if you architect the monolith carefully. That usually doesn't happen though because frameworks don't necessarily promote the practice and projects are short sighted.
  - JamesBarney 6y ago
    It's also really hard. Trying to determine how to split up any code base into logical divisions such that you when adding the next 5 years of functionality you'll have the fewest number of cross division processes is hard. This is why Martin Fowler recommends starting with a monolith and refactoring into microservices unless you have extensive experience building out very similar applications in the same domain.

Starting with a monolith could lead to really difficult refactorings unless you structure the code in a way that it can be easily decoupled.

by eweise 6y ago

Starting with a monolith could lead to really difficult refactorings unless you structure the code in a way that it can be easily decoupled.

dpix 6y ago

The same argument can be made for building separate services too. Could become very difficult to merge data between two services after you had redundant information being saved across the two because of a bad design up-front.

afarrell 6y ago

I once worked in a monolith that was structured in a way that it could have been easily decoupled. It never was because the codebase was so modular and well-tested that the only time we ever felt the need was when trying to assign ownership to runtime exceptions. https://gocardless.com/blog/getting-started-with-coach/ https://gocardless.com/blog/getting-started-with-coach/ was the framework.

mikepurvis 6y ago
Exception triage often requires examining the stack regardless— even if you have multiple processes, you're still going to have errors bubbling up from your pool of shared library code.

stcredzero 6y ago

Law of Demeter! That idea had a lot of influence from Smalltalk, where the natural way of developing was in a monolith. So tactics like that which are about decoupling by default were a good idea in that context. https://wiki.c2.com/?LawOfDemeter https://wiki.c2.com/?LawOfDemeter

JamesBarney 6y ago

Monolith -> microservices : difficult refactoring Microservices -> monolith : difficult refactoring Microservices with poorly chosen context boundaries -> microservices with well chosen context boundaries: very difficult refactoring.

eweise 6y ago
"Monolith -> microservices : difficult refactoring" I guess my point is that it doesn't have to be complicated if you architect the monolith carefully. That usually doesn't happen though because frameworks don't necessarily promote the practice and projects are short sighted.
- JamesBarney 6y ago
  It's also really hard. Trying to determine how to split up any code base into logical divisions such that you when adding the next 5 years of functionality you'll have the fewest number of cross division processes is hard. This is why Martin Fowler recommends starting with a monolith and refactoring into microservices unless you have extensive experience building out very similar applications in the same domain.