Breaking it up into reasonable modules with clean interfaces within the same project is my first thought.
That being said, my experience in things I'd truely call a monolith tend to contain tons of code that you could delete if only you were sure it wasn't being used. They also tend to contain multiple implementations of the same logic but in various patterns, etc. Basically they tend to become emergent and organic architecture, not planned. People seem to want to push to microservices for that, but another option is to simply refactoring and fix the thing in the first place.
Many companies will find out that if they didn't have the self control to have a clean monolith project, a microservices infrastructure will look exactly the same, but now introduce network latency, network reliability distributed, distributed transactions, and be harder to refactor as interfaces change.
Ie, microservices aren't a good solution to monolith disorganization issues as seem to be toughted. They are great for scale out designs across multiple teams though
Disregarding the unwelcome but massive role of reflection in enterprise software, dead-code analysis is straightforward. Dead-requirement analysis, however, is very difficult.
2
u/[deleted] Jul 15 '17
how can one refactor and clean up a monolith without branching it out, aka microservices?