Multiple Applications, how to bring them together?

Question

I have 7 different .NET Core applications (solutions). All supporting a different workflow such as customer request, request for change and much more. However, they do share a similar goal (that is to automate intern processes). I expect that in 2 years there would be 20+ applications as we keep automating more processes. To increase maintainability of these applications and to keep the shared logic together I want to bring these applications together, keeping them central for development (preferably in a different way than just all in one solution).

However, the problem with having them all together, is that building and testing individual processes will require more time. Also having people work on their own "application" in the same project will become more difficult, as each build would use the whole solution.

Is there a "middle ground" in which the applications are central for development, but not have the downsides of one big solution? If so, can anyone give me a good recommendation for an architecture or structure which can help me in this situation?

I've looked into Areas so far but this, like I mentioned above, would increase build time and makes testing individual processes harder as multiple people would be working in that same solution.

TLDR: I want to bring my applications together into one so that I can maintain them better and keep the shared logic central without having the downsides of a big single solution.

Answer 1

Here are some suggestions:

• keep the solutions in one repository. That is probably a no-brainer, since it does not enforce a specific project/solution structure.

• share common logic - well, simply create shared libaries. Note you do not have to put all your applications into one large solution for this, you can simply share the same C# project in different solutions, or utilize NuGet for this purpose

• establish a common build process. Note this is perfectly possible without putting all projects into one large solution. You could either create a build script (or several build scripts) to compile several solutions at once, or you could utilize a build server for this task, or both. This gets important when you have shared libs in different solutions, since if you break backwards compatibility in one library, you otherwise won't get immediate feedback on this if you don't compile all dependent projects and solutions.

• establish a common test process. Works quite similar as a common build process: individual test projects in each solution, and a script or test runner which allows it to run them all at once (for example, on the build server).

• still allow individual deployments - for this, it is important to have stable interface between the applications, maybe utilizing a shared database with a stable schema. Also, a good documentation of the dependencies and the data flow between the applications will become crucial if you need to change something here in the future.

• establish a common process for change management. This is less a technical and more an organizational problem. Establish some common standards, especially for versioning, for documenting changes and for documenting new requirements (in Scrum-speech: a common "backlog").

All these ideas are things I actually managed to implement in my team over the last decade, at least in a comparable fashion, since we were actually facing a similar situation than the one you sketched (just with way more applications, not just 20).

Answer 2

Extract the common code to libraries and publish them as (nuget) packages. Keep each application separate and simply have each reference the establish common packages. Keep the code for each package in its own repository and the code for each application in its own repository. This way you can trigger build/deploy/publish on a vcs event(e.g. merge) only for the modified libraries/applications. This will also let teams work independently on each application, the only coordination being the update of package references to new versions.