在将应用程序拆分为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 (ie 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, ie 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).

eg 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.

Answer 3

the solution point of view is not the major problem I guess. I would choose to organize my projects within folders. One for each bounded context, and the web UI in another one (it could be thought as a bounded context of its own , if one thinks about it).

You might have some shared kernel , shared by all your bc that you might put in a different folder too.

Usually each bc should be independent ( except for the shared assemblies), and your UI should know only the bc through their interfaces (WCF contract for instance)

The global solution might contains every folder and the projects within (MyApplicationName.sln), but you could think of dedicated solution to work only on part of the solution, like MyApplication_BCName with only the bc folder, the shared assemblies and the UI if it fits your needs, and you do not want to have a huge solution to deal with.

Start small, do things as soon as you really need them. Be especially careful of the cross references, the way things are setup in vs is of no importance really. If assemblies are loosely coupled then you can rearrange them the way you want anytime later on.

I am not a first class programmer, I just happened to think that things like this seems to wok well for the latest projects I have been involved with, it might be completely changed in a couple of month (hours..?? ;) )