4 ms·
I wouldn't blame (badly implemented) DI for all the problems of monoliths. I think the real main issue is lack of discipline when dividing the application into
by lmilcin 5y ago
I wouldn't blame (badly implemented) DI for all the problems of monoliths.
I think the real main issue is lack of discipline when dividing the application into modules.
Spaghetti is basically defined as an application where real modularisation does not exist and everything talks to everything.
It is much easier to work with an application when you can abstract parts of it when you are solving your problem. You effectively work on much smaller part of the application.
Spaghetti == you effectively have to take into account possibility of the piece of code you look at interacting with any other piece of code in the application.
Well modularised application == you only need to take into account the contents of your current module and the interface of the other modules you are using.
One reason why microservices sort of work (when done well) is because they force people to think about APIs and how those services talk to each other.
In most cases you could just put these microservices as modules in a monolithic application and expend the effort on ensuring APIs and application structure.
I have successfully rolled back couple microservice initiatives by integrating services into monoliths. This usually results in the team getting back a lot of their time because their environment suddenly became much simpler. Less applications to manage, less network communication, less possible ways for things to break, less frameworks, less resources needed to run the application, less processes (like processes around deployment, release management, etc.), less boilerplate code, and so on. The list is very long.
Of course, when you work on a large monolith vs a lot of small microservices, it is now important to be able to structure your applications. But there is also an opportunity for improvement.
- jstimpfle 5y agoRavioli == you have so many small distinct things on that are hard to stick together, which makes it hard to build a larger structure out of them.
- lmilcin 5y agoThen try to not make the modules too small? Sure, if you were ready to make an entire separate application for it it will not be worse when you turn it into one package of a monolith? Also you can build nested structures with modules (like a larger module consisting of smaller submodules). Divide and conquer. This is how abstraction works in a nutshell. You start with a large problem, divide it into smaller parts (modules), each part you treat as a separate problem dividing it into smaller modules, and so on. There exists no need to have a flat application consisting of hundreds of sibling modules. An application might consist of larger modules, then some of those might have smaller submodules (packages), then those might have even smaller ones (classes), then you have methods, then you have statements, then you have function calls, etc. A large monolith does not have to succumb to spaghetti or ravioli-type structuring. A good developer should know how to structure an application of any size.