How to split a large asp.net mvc3 project into several smaller ones?

Question

visual studio

Hello.
Situation: there is a project that is more than 4 years old and is built on asp.net web forms and asp.net mvc3 technologies. the project was developed by me alone, now it's time to invite additional programmers. I want to logically divide the project into several parts (Forum, Blogs, Message Board, etc.) so that each part is developed by a separate programmer responsible for it. At the same time, the server must have a single site within the same domain with pass-through authentication.
Questions:
1. how to divide a large project into several small ones and how to collect them on one site
2. how to achieve transparent authentication on a site
3. is it possible (and how) to achieve a single use of the Cache, Application, Session collections
4. Does it make sense to divide the database into parts? the base already reaches 70Gb, but in it some tables (for example Users) are used in all parts of a large project.
Thanks for the advice.

Answer 1

I believe that:
1-1) The project should not be divided into several web projects. It is worth separating the business logic into separate "services" and putting them into separate projects. That is, a web project is a collection point, in which there are references to the Class Library of services. IoC will help here. But then all the views and so on will be in one project. But such resources as styles and js should be kept in one place. Therefore, it is not bad.
1-2) Can be divided into web subprojects and deployed into virtual folders. That is, the "forum" project will be a separate application in the forum virtual folder and will be available along the path domain.ru/forum
2) Authentication in the first variant will take place in a single web application and pass through some IUserContext to all modules, where they will decide whether to allow the user to this or that feature or not.
The second option is more difficult. But since the domain is 1 and the key to authentication is a cookie, it will be possible to screw it up to this option.
3) Option 1 - everything remains as it is. The second option is SessionServer and so on. Separate cars of a rummaged condition.
4) I believe that it is not necessary to divide without a visible need. But if it weighs 70 GB, I would share it, since it is difficult to turn over such a volume. Saving and deploying 70GB is probably a few hours? Under each atomic service I would select. Common tables in a common database.
Basically, I would try the first option. Since it is still intermediate before the second. Make a modular architecture. Deal with the base. Remove unnecessary dependencies. If this is not enough, then divide it into subprojects.