Question

I am looking for some advice on how to allow easy customisation and extension of a core product on a per client basis. I know it is probably too big a question. However we really need to get some ideas as if we get the setup of this wrong it could cause us problems for years. I don’t have a lot of experience in customising and extending existing products.

We have a core product that we usually bespoke on a per client basis. We have recently rewritten the the product in C# 4 with an MVC3 frontend. We have refactored and now have 3 projects that compose the solution:

• Core domain project (namespace – projectname.domain.*) – consisting of domain models (for use by EF), domain service interfaces etc (repository interfaces)
• Domain infrastructure project (namespace -projectname.infrastructure.*) – that implements the domain service-EF Context, Repository implementation, File upload/download interface implementations etc.
• MVC3 (namespace – projectname.web.*)-project that consists of controllers, viewmodels, CSS, content,scripts etc. It also has IOC (Ninject) handling DI for the project.

This solution works fine as a standalone product. Our problem is extending and customising the product on a per client basis. Our clients usually want the core product version given to them very quickly (usually within a couple of days of signing a contract) with branded CSS and styling. However 70% of the clients then want customisations to change the way it functions. Some customisations are small such as additional properties on domain model, viewmodel and view etc. Others are more significant and require entirely new domain models and controllers etc.

Some customisations appear to be useful to all clients, so periodically we would like to change them from being customisations and add them to the core.

We are presently storing the source code in TFS. To start a project we usually manually copy the source into a new Team Project. Change the namespace to reflect the clients name and start customising the basic parts and then deploy to Azure. This obviously results in an entirely duplicated code base and I’m sure isn’t the right way to go about it. I think we probably should be having something that provides the core features and extends/overrides where required. However I am really not sure how to go about this.

So I am looking for any advice on the best project configuration that would allow:

• Rapid deployment of the code – so easy to start off a new client to
  allow for branding/minor changes
• Prevent the need for copying and pasting of code
• Use of as much DI as possible to keep it loosely coupled
• Allow for bespoking of the code on a
  per client basis
• The ability to extend the core product in a single
  place and have all clients gain that functionality if we get the
  latest version of the core and re-deploy

Any help/advice is greatly appreciated. Happy to add more information that anyone thinks will help.

Answer 1

I just worried that with 30 or 40 versions (most of which aren't that different) branching was adding complexity.

---

+1 Great question, its more of a business decision you’ll have to make:

Do I want a neat code-base where maintenance is easy and features and fixes get rolled out quickly to all our customers

or do I want a plethora of instances of one codebase split up, each with tiny tweaks that is hard (EDIT: unless your a ALM MVP who can “unbrand” things) to merged into a trunk.

---

I agree with almost everthing @Nockawa mentioned except IMHO dont substitute extending your code architecture with branches.

Definitely use a branch/trunk strategy but as you mentioned too many branches makes it harder to quickly roll-out site wide features and hinder project-wide continuous integration. If you wish to prevent copy/pasting limit the number of branches.

In terms of a coding solution here is what I believe you are looking for:

• Modules/Plug-ins, Interfaces and DI is right on target!
• Deriving custom classes off base ones (extending the DSL per customer, Assembly.Load())
• Custom reporting solution (instead of new pages a lot of custom requests could be reports)
• Pages with spreadsheets (hehe I know – but funnily enough it works!)

Great examples of the module/plugin point are CMS’s such as DotNetNuke or Kentico. Other idea’s could be gained by looking at Facebook’s add-in architecture, plugin’s for audio and video editing, 3D modeling apps (like 3DMax) and games that let you build your own levels.

The ideal solution would be a admin app that you can choose your
modules (DLL’s), tailor the CSS (skin), script the dB, and auto-deploy
the solution upto Azure. To acheive this goal plugin’s would make so
much more sense, the codebase wont be split up. Also when an
enhancement is done to a module – you can roll it out to all your
clients.

You could easily do small customisations such as additional properties on domain model, viewmodel and view etc with user controls, derived classes and function overrides.

Do it really generically, say a customer says I want to a label that tally’s everyone’s age in the system, make a function called int SumOfField(string dBFieldName, string whereClause) and then for that customers site have a label that binds to the function. Then say another customer wants a function to count the number of product purchases by customer, you can re-use it: SumOfField(“product.itemCount”,”CustomerID=1″).

More significant changes that require entirely new domain models and controllers etc would fit the plug-in architecture. An example might be a customer needs a second address field, you would tweak your current Address user-control to be a plug-in to any page, it would have settings to know which dB table and fields it can implement its interface to CRUD operations.

If the functionality is customised per client in 30-40 branches
maintainability will become so hard as I get the feeling you wont be
able to merge them together (easily). If there is a chance this will
get really big you dont want to manage 275 branches. However, if its
that specialised you have to go down to the User-Control level for
each client and “users cant design their own pages” then having
Nockawa ‘s branching strategy for the front-end is perfectly
reasonable.