Recently, I wrote about microservices and it's impact on software engineering. However, microservices doesn't exist as the only form of software architecture around. We also have monolithic architecture which is the opposite of microservices. While microservices is built on the concept of creating software solutions from tiny pieces that can be swapped out, fixed, or replaced, monolithic architecture involves building solutions as a lump project.

Monolithic architecture is more or less a tightly coupled software solution because it's not open to change, if you have issues with the functionality of the product and want to extend it or include more functionality, you're better off rebuilding it. It's not all doom and gloom for monolithic architecture (which more of less gives off the dinosaur feeling), this architecture is rather useful when you're working a project that you don't expect to change or evolve.

When building a software solution, one of the first things software engineers decide on is what architecture to use, it's rather easy to choose when you know the scope of the project and if the project is meant to perform a specific task. Monolithic architecture has the plus of being faster to build, there are less moving parts and a single software engineer can build the entire solution (depending on the size of the project).

For junior developers, architectural pattern or design isn't a major concern as junior developers aren't tasked with making the architectural decisions. Most junior developers tend to use monolithic architecture in the course of learning (by default). An understanding of architecture does make sense as it helps the junior dev begin to perceive software as more than just code, issues regarding scalability and reusability begin to creep into the thought process of junior developers who know about architecture.