Approach to refactor multi-portal solution asp.net mvc -

i refactoring massive monolithic asp.net mvc solution (which runs website/portal) , extracting class libraries

1. common business logic (that can used create similar portals)
2. core business logic (that can used domain logic)
3. common repository logic
4. core repository logic
5. portal specific business logic (if common business logic doesnt it)
6. portal specific repository logic (if common repository logic doesnt it)

the problem approach see @ time of introducing similar portals have create specific business logic layers , repository logic layers if need arises , increase number of projects in solution (with fear of going unmanageable)

how achieve multi-portal solution in terms of manageable projects?

i’ve been in similar situation having bunch of mvc sites sharing lot of common functionalities.

what we’ve done first isolate common things in separate solution (we’ve called "global"). solution structured same way mvc sites , contains "global" specific business logic, interfaces, entities, repositories , ui components (i.e.: headers , footers, login functionality, ...). common functionalities organized in portables areas can deployed, need 1 of them in 1 of mvc sites, using dedicated nuget package.

in order able test portable areas we’ve developed, without need of deploying them, we’ve created "launcher" site within global sln. site never deployed; has been built testing purpose.

our mvc architecture not common n-tiers architecture, onion architecture. please have @ related stackoverflow questions if you’re interested. our mvc sites using structuremap di in order bind interfaces used right implementation, @ start-up. global has own di container configuration section. thing have things running properly, calling these 2 methods within global.asax file of mvc site host portable areas:

globalconfig.init(); globalconfig.registerallareas(); 

the init method structuremap binds interfaces right implementation , registerallareas methods registers portable area routes , bundles. these 2 methods must called before registration of mvc site own routes, bundles , di stuff.

here’s global sln folder structure:

web.xxxx projects different portable areas need create. it’s better separate things avoid having need deploy if mvc site needs user account shared functionalities.

here’s closer @ 1 of web.xxxx project structure:

the portable area project called xxxx.area, contains views , controllers of area. has xxxxarearegistration.cs defines routes , bundles of area.

the view model , builders in separate project called xxxx.viewmodel.

xxxx.domain , xxxx.domainmodel projects service implementation , domain model of area stored. xxxx.data area’s repositories implementations are.

all areas service , repositories interfaces stored in contract project (see fig.#1) , can separately deployed specific nuget package.

this big picture of way organize things here, not hesitate if need more information , details if want go kind of architecture.

hope helps!