What is the difference between Monolith and n Layer?

Question

i have a few questions regarding monolith and n layer architecture.

First, whats the difference between Monolith and n Layer architecture?

Second, let's say I have a single Visual Studio solutions that consist of multiple projects such as:

1. Presentation Layer
2. Service Layer
3. Business Layer
4. Cross Layer
5. Data Layer
6. Unit Test

Is that considered as Monolith or n layer architecture?

If I have microservices that consist (let's say) 3 Web API and I build each service in single separate Visual Studio solutions, it is ok to implement my previous project structure (service layer, business layer, data layer, etc)?

Thank you very much and sorry for my bad english.

Answer 1

Ok, so Monolith solutions are the old way of basically having ONE project in a single solution which has all the code in there.

So lets say you're doing a website.

This means you would create a single Solution with a single Project and all the database calls (persistence), logic (business logic/services) and finally figuring out how to display that calculated data (presentation) are all mixed in , in a chaotic way in that single project. Sometimes people have tried to split the concerns into folders, but usually it's a large mess. This makes support/maintenance of the application a nightmare. If you wish to make a single change to the website/application, the entire application will go offline/restart.

vs

n-tier / n-layered solutions/applications. This is where we have multiple projects (usually) in a solution which separates the concerns of our application in to more bite-sized components. This enables us to keep the problem space to a single area making it waaay easier to maintain and support. This also enables easier reuse of your various components/projects/dll's into various other subsystems of your application. It's way better than the old monolith architecture pattern. But, if you wish to make a single change to the website/application, the entire application will go offline/restart still.

Finally, we have microservices. This is a more modern concept and continues on with the evolution of monolith -> n tier -> microservices. This is when we split up our application concerns into individual applications so that when one microservice needs to be updated, then entire appilication hasn't come to a stop. Sure, the part of the application that has a dependency on the microservice might stop/be affected, but it's possible that the entire app is not.

Lets use an example:

I have a website that sells Pets (cats/dogs/etc). I might split this website up into separate microservice mini websites:

• authentication
• administration/backend management (think: stuff only an admin can see)
• public website
• animal inventory
• shopping cart

So each of those are a single website, like the the n-tiered architecture'd application. So it would have a presentation layer (the MVC website). some database project and some basic services.

Now each of the 4 microservices (mini websites) all do that.

Now, you need to update some stuff with your administration section of the website. You take that offline and the main website stays up. People can still browse and buy animals.

So yes, it's a nice thing to implement microservices if you application is large enough that it has areas you might want to segment. It does add some more complexity but it also brings about it's own advantages.

And yes, your microservices should follow the n-tiered pattern if you application isn't some silly hello-world app or some Research Project.