架构：多个网站。 一个代码库。 自定义代码

Okay. I am currently building an php application (platform) which will be deployed multiple times, only with different configurations. The application consists of a backend and frontend. Through the backend, we are able to configure which modules are active, what there settings are and how the platform looks like.

We expect that customers will start asking for specific functionality on their platform. This means that there platform will be different then the other ones. But, we maintain one codebase.

What's the best way to solve this? Since we keep on fixing bugs and developing new features, it should be easy to take care of all the platforms. We have a script which we use to deploy our platform updates to all our platforms.

Should we convert all our functionality into plugins so every platform can be updated manually if they want? So if a customer wants something differently then the original plugin, we duplicate the plugin and create their own customer-plugin? But is the code easily to maintain then if we ever decide to update the plugin?

Or should we write exceptions in the code for every customer?

Should we have separate files which override the base files for every platform with custom code?

What's the best way to go?

The big trick will be balancing the diverging needs of customers without ending up with a massively complex system that is impossible to maintain. Here's a few approaches you should consider:

• Dependency Inversion: there's lot of material on this subject, basically it's a way of structuring a system so that different parts within it depend on concepts rather than concrete implementations. This will allow you to swap those implementations for different customers. It can be used for everything from deep business logic and algorithms to data-providers to UI widgets. I'm not sure where the best place is to start with DI (and I come from a .Net background not a PHP one) so here's the Wikipedia entry as a start.
• Identify the sorts of things users will want to change and isolate those things into things which can easily be swapped out using DI or some other practical approach. Having done that try very hard not to introduce variations into the framework code-base (the core that basically "hosts" the swappable bits.
• Keep the dependency tree as clean as possible.
• Start with a PoC / Prototype. Building frameworks is very hard. Your first attempt might work ok but your second and third attempts will be better; experience counts for a lot.
• Put some effort into making the system easy to test, both during development and after deployment. With all the moving parts you will want good diagnostics to help you isolate issues and help with integration.

Edit: Finally, if you're not already aware of them, there are existing PHP frameworks that you might be able to use or simply borrow approaches from - the PHP Open Source community is fairly strong. Check out the Zend Framework.