Which considerations should I make before splitting an application into several solutions in Visual Studio?

Question

In the past, my projects has grown to be hard to manage, especially when I have to revisit after a few years to redo or make significant update to one part without having to redo everything. This time I'm focusing hard on making it easy and possible to make a "pluggable" application design to allow me to revisit and redo one part without touching everything.

I'm thinking of this structure:

So what I want is to be able to work on Bounded Context 2 and expand that with a lot of new functionality the coming month/years while Bounded Context 1 is left as is. I will also work on the UI, especially the parts concerning Bounded Context 2. I would also like to give users the ability to work with bounded context 2 from other devices.

Preferably even the web technologies used in the UI of bounded context 2 will be updated since this is our primary area of focus and is used the most, so it might even be smart to put that in its own UI project for web and have a "landing" site that gives common functionality like managing users and let users log in.

Right now I'm thinking of seperating all of this into seperate Solutions in Visual Studio to ease management. But I could make a folder for each in one solution and put everything there.

My question is what is the recommended way of doing this, and what should I consider before seperating into different solutions?

Are there any best practices of how to manage this? Anyone with experience of what works and not?

Btw: since this is divided by bounded contexts there will need to be communication between parts of the system, although no direct dependency (i.e. context 1 manages and maintains business logic for registering employees that again are needed in context 2).

Update I realize some more information is needed.

There are more bounded contexts than these two. None of them are really like a department, i.e. Employee Managment is the context managers are in when they need to organize/archive information related to managing others, and also get reminders on important events. Purchasing is the context employees are in when they purchase goods for a department and do inventory, there might be 20-40 organizational departments that use this. I'm considering if "reporting" is a seperate bounded context (though without very much interesting logic and behavior). These tend to start small providing basic functionality, then grow with time as more functionality is added and people "discover" new needs. They are updated separately, and I hope some of them will grow into larger systems in time even though they start solving rather basic needs.

Answer 1

So, you have bunch of code and want to work on some part of the code without loading projects related to other parts. Then yes, you can have each part as a separate visual studio solution.

Key point is that VS solution is just a [.sln] file describing which projects are grouped by this solution. Don't make separate copies of projects for this purpose only. You must maintain all projects just once (one copy for each), and then create separate solutions and include projects which you think are related to this solution (this part of the code).

e.g. you might decide that "Employee Management" is a solution consisting of only 3 (out of whole bunch of 40) projects. Then you go ahead and create a solution which contains those three projects. Probably you will end up having separate smaller solutions which is convenient to work in separation from others.

You may as well consider having one big solution consisting of all projects in it (again, each project has only one instance, but can be a part of several solutions). This kind of big solution may be useful for major operations such as Build/Release preparation.

What I suspect is that you are trying to exaggerate the importance of a solution. In reality, all the code you have is one huge unity because they reference each other and cannot be built probably without [re-]compiling others. Even though you may try to come up with the solution structure which somehow corresponds to your business needs, still it seems to be another direction of a problem which is not related to solutions. That may be something like solving a problem of dividing into assemblies, dynamic loading and extensibility, etc.

Conclusion: split code into solutions depending on the convenience you want to achieve when working with the source code, because that's simply dividing the source into sub-parts, nothing more.

EDIT/Addition:

You may as well decide to split the solution into independent solutions, but that's something different. That would mean the solution projects may only reference the output (dll, exe) files of other projects in other solutions. That could be done when each solution treats another just like a 3-rd party code (no direct project references, but only output referencing).

Answer 2

I think when deciding if you should have multiple solutions, the answer is really do you envision one (or more) of the assemblies that make up your bounded context being used in other different applications, which will expose some of all of the exact same use cases your bounded context manages. If that's the case, then a separate solution makes sense. But if all your UI layers are conceptually the same application released at the same time, then I'd keep it in one solution, unless you have so many projects that Visual Studio becomes unusable.

I'd be suprised though if you really are going to have another application making use of the same bounded context though. If you think about it, would you ever want a newer version of the logic deployed ONLY to your web service, but not your windows forms application? Probably not, as the logic changes may introduce odd problems where the data is not what one of the application expects.

What you have sounds like a platform, and all pieces (UI layers) of that platform should be should be running the exact same logic.