18

The company where I am currently employed is struggling with an architectural decision for our range of applications. At the moment we have a couple applications that have common parts (think like a calendar module). Until now we kept on copying code from other existing application, but in the future we want to evolve our applications to a more modular design:

Our situation

As you can see in the picture above it is possible to have different versions of modules per application.

We are considering to possible solutions:

  • Building a core application framework where we can install our modules in. We're think about a tool like Nuget to accomplish this.
  • Building one application where all our modules are included in (=one code base), but the customer only gets the functionality that is activated for him. We're forseeing some problems with versioning here.

Any suggestions on this? We can't be the first company who struggles with this problem?All our applications are ASP.NET MVC 4/5 web applications, built with Razor Templates or JavaScript templates (knockout.js). All of our applications are deployed on Microsoft Azure and we have extensive inhouse knowledge of buildscripts (MSBuild), CI Servers...

yoerids
  • 918
  • 1
  • 8
  • 19
  • 1
    I've worked in a previous position with a similar setup. What we did was have one all-encompassing solution that includes all of the projects. The reusable elements of your applications would live in a shared project in the solution referenced by each of your web applications. The one thing that this doesn't address is different versions of modules, why is this the case? I think that it's only going to cause you headaches in the long run. As for access to different modules for each client, that'd be governed by your permissions/security structure in your application. – Mathew Thompson Feb 04 '15 at 12:54
  • You could also make each module an individual project, and import the projects into each larger project. I prefer this to the large solution that encompasses everything simple because I hate searching through a large tree structure. Both achieve the same result though. This also allows you to keep old versions of modules and add those to the larger project/ – Lee Harrison Feb 04 '15 at 12:56
  • @mattytommo we work with paying customers. It is possible that we want to keep a certain customer (=application) on version 1.x because he wants it that way or because he didn't pay for the new version 2.0... – yoerids Feb 04 '15 at 12:59
  • Ah right I see, but technically restricting features can be managed within the module itself. For example if you wanted to add a Reminders feature to your Calendar, you would restrict that new feature **within** the module to only your paying customers. This is exactly what we did in my old workplace. That's how most applications I've worked with manage stuff like this. – Mathew Thompson Feb 04 '15 at 13:01

2 Answers2

8

Having separate project/assembly for each module and delivering it as Nuget package is definitely a good strategy.

Advantage:

  1. Can maintain and release multiple version. Different client get different version.
  2. Installation of latest or specific version supported through Nuget. This helps during development where App A developer can target 2.0 version of module A while App B developer can target 1.0.
  3. Single source base with separate branches for each version. Client using 1.0 request a change will get code from branch 1.0 with just the fix requested.
  4. Each module can be released or updated independently.

Challenges:

  1. During development debugging assembly code that's installed using Nuget. Nuget supports it inbuilt. We achieved it in our case (Framework being used by multiple platform).

  2. Code changes required in module code (a bug or a new feature required). Well this is tricky:

Option 1: Same developer just go ahead and make that change, create new package and install new version in his app. Got to authorize the change as it is critical code.

Option 2: A designated team responsible to fix issue or change request in framework code.

SBirthare
  • 5,117
  • 4
  • 34
  • 59
2

You can also try using the plugin architecture, just build the different modules that makes up the application as a plugin, then build the module that is required for every application as a single code base. In this case, installing a component for any particular user, will be a matter of adding or pulling out plugins. Many large projects makes you of this particular architecture as it reduces copy and paste, increases and reuse and speed of development. You can check nopcommerce an open source project for an idea of how it is done.

Bhavik Patel
  • 1,466
  • 1
  • 12
  • 28
Cizaphil
  • 490
  • 1
  • 6
  • 23