Organização múltipla de códigos de aplicativos Zend

Durante o ano passado, tenho trabalhado em uma série de aplicativos todos baseados na estrutura do Zend e centrada em uma lógica de negócios complexa à qual todos os aplicativos devem ter acesso, mesmo que não usem todos (mais fácil do que ter várias pastas de biblioteca para cada aplicação, pois estão todas ligadas a um centro comum).

Sem entrar em muitos detalhes sobre o que é especificamente o projeto, estou procurando informações (como estou trabalhando apenas no projeto) sobre como "agrupei" meu código. Tentei dividir tudo de uma maneira que remova as dependências o máximo possível.

Estou tentando mantê-lo o mais dissociado possível logicamente, para que, em 12 meses, quando meu tempo acabe, mais alguém entrando não tenha problemas em estender o que produzi.

Estrutura de exemplo:

applicationStorage\ (contains all applications and associated data)
applicationStorage\Applications\ (contains the applications themselves)

applicationStorage\Applications\external\ (application grouping folder) (contains all external customer access applications)
applicationStorage\Applications\external\site\ (main external customer access application)
applicationStorage\Applications\external\site\Modules\ 
applicationStorage\Applications\external\site\Config\
applicationStorage\Applications\external\site\Layouts\
applicationStorage\Applications\external\site\ZendExtended\ (contains extended Zend classes specific to this application example: ZendExtended_Controller_Action extends zend_controller_Action )
applicationStorage\Applications\external\mobile\ (mobile external customer access application different workflow limited capabilities compared to full site version)

applicationStorage\Applications\internal\ (application grouping folder) (contains all internal company applications)
applicationStorage\Applications\internal\site\ (main internal application)
applicationStorage\Applications\internal\mobile\ (mobile access has different flow and limited abilities compared to main site version)

applicationStorage\Tests\ (contains PHP unit tests)

applicationStorage\Library\
applicationStorage\Library\Service\ (contains all business logic, services and servicelocator; these are completely decoupled from Zend framework and rely on models' interfaces)
applicationStorage\Library\Zend\ (Zend framework)
applicationStorage\Library\Models\ (doesn't know services but is linked to Zend framework for DB operations; contains model interfaces and model datamappers for all business objects; examples include Iorder/IorderMapper, Iworksheet/IWorksheetMapper, Icustomer/IcustomerMapper)

(Nota: as pastas Modules, Config, Layouts e ZendExtended são duplicadas em cada pasta do aplicativo; mas eu as omitii porque não são necessárias para meus propósitos.)

Para a biblioteca, este contém todo o código "universal". A estrutura do Zend está no centro de todos os aplicativos, mas eu queria que minha lógica de negócios fosse independente da estrutura do Zend. Todas as interfaces de modelo e mapeador não têm referências públicas ao Zend_Db, mas envolvem-no em particular.

Portanto, minha esperança é que, no futuro, eu seja capaz de reescrever os mapeadores e dbtables (contendo um Models_DbTable_Abstract que estende Zend_Db_Table_Abstract) para dissociar minha lógica de negócios da estrutura Zend, se eu quiser mover minha lógica de negócios (serviços) para um ambiente de estrutura não-Zend (talvez alguma outra estrutura PHP).

Usando um serviceLocator e registrando os serviços necessários na inicialização de cada aplicativo, posso usar versões diferentes do mesmo serviço, dependendo da solicitação e de qual aplicativo está sendo acessado.

Exemplo: todos os aplicativos externos terão um service_auth_External implementando service_auth_Interface registrado.

O mesmo com aplicações internas com a Service_Auth_Internal implementando service_auth_Interface Service_Locator :: getService ('Auth').

Estou preocupado que possa estar faltando alguns problemas possíveis com isso.

Estou pensando em um arquivo config.ini para todos os externos e, em seguida, um aplicativo separado config.ini substituindo ou adicionando ao arquivo config.ini externo global.

Se alguém tiver alguma sugestão, eu ficaria muito grato.

Eu usei a alternância de contexto para funções AJAX nos aplicativos individuais, mas há uma grande chance de que externo e interno obtenha serviços da Web criados para eles. Novamente, eles serão separados devido à autorização e a diferentes serviços disponíveis.

\applicationstorage\Applications\internal\webservice 
\applicationstorage\Applications\external\webservice

Por fim, alguns códigos serão específicos da "lógica de negócios" do seu aplicativo e outros são "código da biblioteca". Por exemplo, algo que valida a entrada de formulário geralmente pode ser considerado como "biblioteca", enquanto algo que ajuda a calcular as ofertas disponíveis para o cliente X em um determinado mês é claramente "lógica de negócios".

Esse é mais um problema de controle de versão e há várias maneiras de você esfolar esse gato em particular. Ferramentas como Maven (e até certo ponto Phing / Ant) são criadas para montar aplicativos de várias fontes diferentes - com base em algum tipo de arquivo de configuração externo (geralmente XML). Isso significa que você pode manter repositórios separados para o código da biblioteca e importá-lo para o Aplicativo X, se necessário.

Se você tiver controle sobre seu host, poderá pensar em mover as coisas da biblioteca para o caminho de inclusão - e mantê-las como um projeto separado de longo prazo.