I'm working on a project that requires from me to make modular and extendible code structure. This code should be able to support multiple clients. The good news is that code should not do anything spectacular. I will explain this in more details later in the question.

So now I have around 30 branches for about 60 clients. Some clients needed their own branch because at the time it was easier to just separate their code from everyone else’s so that over time grow to 30 separated codes, that are very very similar.

So now architecture could not be more simpler. Request comes from client in XML form and then I process I return XML. Process part is mostly CRUD. Nothing fancy. I have two front controllers one for actions (INSERT, UPDATE, DELETE) and one for requests(SELECT). Then that front controller just includes script that client requested. Every request and every action has their own dedicated script. There are not a single class in the project. Everything is written in procedural way.

So in the new App structure the goal is to have one main branch that will all clients use and it will be managed from conf file.

I'm telling you all this because I'm not sure how to structure everything. I don't have much experience with OOP I know the concepts and theory but its harder when it comes to actual coding in that style.

My idea now is. I'm leaving two front controller for action and request because that doesn't require any change from client-side of application and that is important for now. They will now serve as only get request and echo it back. They will also call ActionController and RequestController. They will be a little smarter. They will know how to recognize which request/action client sent and then they will make new object of that class.

Every action/request has some steps that it needs to do. So i'm thinking that every class need some public method 'execute' that will just call method of that class by the order that it needs to, but I'm afraid that, that is also procedural way of thinking just it wont be in global score but in Class.

$client_request = new $fullClassPath(new $mapperClassPath);
$response = $client_request->execute($request);

Also How to handle Database, I probably should make actions on database as abstract as possible.

Configuration file will be very important, so I don't know if it's the solution to make class for every feature and include classes if that feature field is set to true in config file?

Every action has its own response to client and it can be pretty heavy xml. What is the solution there. Should I have a Response class that will handle that. Im afraid that the class will be pretty heavy because there are around 20 actions and 5 requests and everyone have different xml response.

So every help is appreciated with someone who had experience with similar projects, some links on good articles also wouldn’t hurt.

I should mention that language I’m working with is vanilla(plain) PHP.

closed as too broad by GlenH7, Arseni Mourzenko, Kilian Foth, Bart van Ingen Schenau, gnat Apr 6 '15 at 10:02

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.


It sounds like essentially the problem is that you have 30 processes which are similar but vary in inconsistent ways and you want to avoid duplicating code as much as possible while still being able to change any aspect if required.

In that case then the template method pattern can be very useful.

The basic idea is that you'd implement a base/abstract class which more or less functions in the most common way, then for each customer you create a child class which only overrides the methods which need to be changed.

For example:

abstract class BaseCustomer {

    protected $someValue = 5;

    protected function someProcess() {
        return $this->someValue * 2;

    public function execute() {
        return $this->someProcess();


class FirstCustomer extends BaseCustomer {
    protected $someValue = 10;

class SecondCustomer extends BaseCustomer {
    protected function someProcess() {
        return $this->someValue + 2;

Calling ->execute() will return 20 for FirstCustomer and 7 for SecondCustomer.

A further step you can take is to use composition in combination with a template pattern to separate different components of your modules.

For example let's say you have processes which send a CSV file in 5 different formats via either email, FTP or HTTP depending on the customer. You can have two sets of modules: one for the file format and one for the transport method.

Then go something like:

$format = new CustomerOneCSVFormat($data);
$transport = new FTPModule();

In that example you could support 15 different combinations from only 8 classes (plus the base/abstract class).

When designing your base class it's important to keep in the internal functions short and divided along the lines of what you're likely to change on a customer-by-customer basis, that will avoid having to copy large chunks of code to child classes just to change a few lines.


It's hard to say how to structure your application without knowing the differences between each 'branch'. What I would do is compare the functionality of each branch and distill the common denominators. Put these into classes that you use for each client. The parts that differ from client to client I would then put into adapters or strategies that (optimally) share a common interface.

We had the same problem with a codebase I inherited. Some pointers I used in that project:

  • Heavy use of adapters or strategies.
  • Use of dependency injection to swap out different classes for different clients.
  • If a client needs a special exception, see if it can instead be added to the generic classes using some configuration.

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