I have a product which is a combination of mobile apps and webapi . I am working web API. The webapi part created earlier and it build with layered model. Even thought this does not have a business layer (API and Data access), each one created as seperate project in the solution. Now I just optimized the code some level and changing existing data access layer with repo and unit of work pattern etc.

I have one more challenge. Currently, the product published as single and hosted in EC2. Now the product going to have multiple variants. I don't know the naming is correct but I mean multiple editions like visual studio have professional, enterprise etc.

So my product has a basic edition, intermediate edition and enterprise edition etc. Namings will be different. I am totally confused about how to develop each module as pluggable so that I can add to each edition when deploying.

I M totally zero here so I just thought like that.

  1. Create separate copy our product and do the modules in needed copy

  2. A single product and each add-on module as seperate product and add while deploying.

  3. How to handle deployment

  4. How to handle product version and edition naming

I know this does not have single answer.but can anyone guide me go on . Even an article, blog or videos will help. I will learn and come back for specific questions.


The product variants have -

  1. Add on Modules / Features
  2. Some variants have different Modules / Features

Currently, Product has customized versions for some customers. So I handled that with separate build/solution. enter image description here

  • 5
    Simplest option is to have single deployable and have features turned on/off depending on configuration/licence. – Euphoric Dec 16 '18 at 13:45
  • 2
    What will be the essential differences between your variants? Do they only differ in some additional modules which have to be added or not? Or do they differ in features which cannot be seen as clearly separated modules? Honestly, giving you any recommendations without that essential information is IMHO quite nonsensical, so please clarify. – Doc Brown Dec 16 '18 at 19:49
  • @Euphoric: Yea I thought for that but I don't have any idea how to handle while deploying. How to handle versions of each variant etc. – Akhil Dec 17 '18 at 5:31
  • @DocBrown: I updated with the scenarios – Akhil Dec 17 '18 at 5:31
  • 1
    No idea what that strange tables means, seems just to mess up your question. – Doc Brown Dec 18 '18 at 6:37

I would recommend to use a multi-project structure wherein each variant has its own set of projects that define the deployable artifacts. "Enterprise" features in modules should usually use feature toggles to keep it simple. The edition projects provide the configuration to toggle the features. Something like this:

  • Project-Root
    • Modules
      • Server-Api-Base
      • Mobile-App-Common
      • Mobile-App1 (depends on Mobile-App-Common, Server-Api-Base)
      • Mobile-App2 (depends on Mobile-App-Common, Server-Api-Base)
      • Server-Base (depends on Server-Api-Base)
    • Enterprise-Edition
      • Mobile-App-Enterprise1 (depends on Mobile-App1)
      • Mobile-App-Enterprise2 (depends on Mobile-App2)
      • Server-App-Enterprise (depends on Server-Base)
    • Community-Edition
      • Mobile-App-Community1 (depends on Mobile-App1)
      • Mobile-App-Community2 (depends on Mobile-App2)
      • Server-Community (depends on Server-Base)

I see the following advantages:

  • Feature Development
    • You naturally think about all variants when writing new features.
    • You can test those features in edition configurations very early.
    • You can start all parts of an edition very easily for fast developer feedback
  • Refactoring (you can have this w/o one big multi-project but it is more natural this way)
    • No pain when moving functionality between editions or modules
    • IDE support is very good with this setup
    • Usually problems are directly reported by the compiler
  • Testing
    • You can easily create tests that span over multiple editions
    • Test data can be shared easily
    • You can test full edition configurations easily because they reside in their own subprojects
  • Build and deployment
    • You can easily share build and deployment logic between the editions
    • All your code has one version and it stays so naturally. It's easier to manage bug reports etc.
| improve this answer | |
  • ok fine. My understanding from this is I need to include multiple groups of projects (each variant is a separate group) in the solution by separating with a directory. Here if any changes happened in the common module, then I have to include in all project groups. correct? – Akhil Dec 17 '18 at 5:34
  • Yes, or you always open all groups in your IDE. Please note that I only sketched out how the project structure might work on a structural level.You can also have all editions in one directory as long as each has its own associated set of projects. I think most build systems / IDEs support also variants, so in theory you do not need one project per artifact / target / variant. But very often you will need custom configuration files, icons etc. in your variant, which find a nice place in "variant projects". In my experience build and IDE configuration is also easier with one "target" per project – chromanoid Dec 17 '18 at 9:08
  • ok understood. I also have custom made for some clients. So all have a separate project group (Current I have 2 separate builds for 2 clients in addition to the main one). So common functions should be done in all groups and deploy seperately – Akhil Dec 17 '18 at 9:22

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.