Will decoupling be beneficial in a redesign of a legacy application?

I am working on a company running several internet shops. We are about completely rewrite the whole code: site content and products management, order processing, partner relations, accounting, customer base and other. Currently we have a system, where all the stuff (all internal management sites, business-logic and internet store web sites) is tightly coupled running on a single LAMP instance, and absolutely all data is located in a literally single garbage database. Because of this (and also because of 10 years development, partially rewritten from perl, php code quality) introducing new web-store, redesigning any existing o开发者_Python百科r changing anything in logic is kind of impossible task.

In order to not only rewrite old code but also optimize system architecture, I am surely decide to separate web sites (each other from), decouple "business cores" from web sites and business cores each other from.

From one point all web shops mostly sells the one common product base, they are kind of the mirrors, sometimes just designed differently to target international customers (titles and descriptions may vary). Stuff we sell is a service product that depends on local partners but with common predefined product range. But in several cities we have special prices, in others cities we offer enhanced product range in addition to common range. So we also run dedicated web-sites focused on a single city, web-sites that sells special offers only and so on.

In contrast to solution where each web site have their own product database (that sometimes is copy of another) I am considering to compose all the products descriptive information, availability in different cities and/or different sites and prices into a single isolated product management system and serve all the info thru SOAP. And every time any user will visit any site, site will consume that service (providing some parameters) and then list the products. Apparently common access library can be developed to include it to every site.

1) Is that solution adequate? Will it perform fast enough without caching? We have limited resources (1.5 developer) so I am trying to not introduce (when possible) additional technical complexities like requirement to use memcached on every site.

2) Suppose, I reconstruct the system in a decoupled manner. Will the benefit be adequate to engage myself in all the work with memcached etc.?

3) It is reasonable to cache data on SOAP server side, but not in web-site and continue make thousands of soap request?

All systems will be decoupled, some the web-site related of them is for example order processing, customer authorization (common accross all web-sites), payment receiving integration and etc. In case of order processing when order is need to be placed web-site remotely put it in order processing system thru SOAP, and then in turn expose their own SOAP server to receive order status updates.

4) Is that decoupling SOAP -centric philosophy right?

Technologies to use are nginx, php, MySQL

Eduard. I'll try to answer your question. Firstly I'll give a little preamble and then point by point:

I. It is practically obvious that a complete rewrite must be an optimization of system architecture, just to have some sense. In your particular case, introducing "some" modularity into the architecture IS an optimization of such kind. (I would also stress, that until you're bound with some AR-style application framework, there must be at least three recognizable corpora in your code:

1) model is a very "general" term nowadays, but it still makes sense to separate all the abstract knowledge of the domain (objects and relations) from anything that doesn't have much to do with that
2) data persistence organization, which is basically a "data access layer", but I hope that it can be not so thick due to an ORM framework of your choice.
3) other library code, which is none of the above

With this setting, you could make all your massive code part redistributable and shareable across as many virtual nodes as it may be needed.

II. A minor remark that I could make is concerning the general idea of application quality. You will be forced to find a balance between the conciseness of your system, the project deadline and the resulting performance metrics. These are all contradictory requirements, still I cannot say what is the main in your case. But too general and abstract code may turn out to be hard to maintain, so you will have to have at least a valid description of functional requirements of the resulting system.. valid for at least 3-5 months I guess.

Now the relevant part:
1) Adequate? At least it must be more adequeate than the stuff you have now. Will it perform fast without caching? I don't know, really, but I think the short answer is "no" - I suppose you mean exactly target data caching (large data-sets), which I cannot see fitting to anything memcache-like. (BTW you have no 1.5 developer, but (1 - 0.25) developer, what gives you 0.75 I guess :))
2) As a suggestion, you could write the business-logic-related agents in something less shitty than PHP. Other than that - depends on your personal experience with the technologies potentially involved.
3) I think that either way is possible, still I think that caching on the web side is better, cause you could eliminate a possible bottleneck
4) For that concrete example? Not in my vision. As an argument, I could state that integrating two websites(!) is an awful process in general.