2

my question is going to be somewhat philosophical and "architectural oriented" so bear with me.

Right now we have existing Java web application built on top of Spring and JSF(facelets) with maven. These are basically our tools that limit our scope of possible solutions.

Now to the point. We need to implement a fork of this application that will be running on different domain for different "end consumers" and implement some change requests for both versions, but code base of these versions will probably always be ~90% same. Same change requests can be defined for implementation in both versions simultaneously BUT separate change requests only for chosen version might come as well. We have no control over what change requests there might come in later in project (but we are expecting quite a few). The differences in functionality may occur both on bean and view part of the application.

We don't want to create 2 completely separate projects as implementing changes might sometimes mean implementing them twice. THE BIG ISSUE is that we expect to have even more forks in the future so the effort might multiply even further.

The question is what ways of control or architectural patterns can we introduce to promote better maintainability of our projects. One solution might be for example:

  • using Spring profiles to inject proper components based on current fork of application and completely separating view (xhtml) implementation.

In summary we are looking for best way to implement application wide changes that can be isolated and activated only based on some context variable (how to propagate it everywhere?).

Any input, idea or new perspective is appreciated.

Jan Mathauser
  • 129
  • 1
  • By isolating a common, core API into its own project and using it as a library for each fork – amphibient Feb 06 '13 at 17:12
  • Problem is we cannot define any core API... because the changes might target the whole scope of application. Business logic and data are separated in another project and this web application I'm talking about is only getting it's data from Web services... does some view specific transformations and presents it to user. But it's somewhat large in scope so maintaining two (later even more) copies might be challenging. –  Feb 06 '13 at 17:19
  • do you implement component model and SoC? http://en.wikipedia.org/wiki/Component_model http://en.wikipedia.org/wiki/Separation_of_concerns. if so, i would not concern myself with what MIGHT be needed in the future and dump all COMMON COMPONENTS into the API and gradually, as the need arises for customizing a previously common component, move it into the forks. again, don't concern yourself with what MIGHT be needed in the future, start with what's needed today. – amphibient Feb 06 '13 at 17:24

2 Answers2

1

Your problem is one of how to support a product line rather than a single product. Luckily you're not the first person to have this problem. There is a large community of people who work in this area, both industrial people and academics.

If you search for "software product lines" via your favourite search engine, you'll find lots of sites, books and other resources.

There are various patterns, going back to GoF, that allow variation to be plugged into a design in a controlled manner (Strategy immediately springs to mind, allowing interchangable implementations of a feature). However, you need more than lots of individual changes - you need configurations of your product for particular customers that combine a number of variations together. That's where the thinking from the product line community comes in (variation points and product configurations in particular). As you say you can use technologies such as Spring profiles to implement this, but to avoid an almighty mess, you need to have a clear model of what you're trying to achieve to start with.

Eoin
  • 111
  • 2
0

You need to look into multi-tenant techniques, including

  • partitioning your db to allow multiple clients, or db-per-client
  • compositing your app, using switchable components
mcintyre321
  • 335
  • 2
  • 4