Organisation de plusieurs codes d'application Zend

Depuis un an, je travaille sur une série d'applications toutes basées sur le framework Zend et centrées sur une logique métier complexe à laquelle toutes les applications doivent avoir accès même si elles n'utilisent pas toutes (plus facile que d'avoir plusieurs dossiers de bibliothèque pour chacun) car ils sont tous liés par un centre commun).

Sans entrer dans les détails de la nature spécifique du projet, je recherche des informations (car je travaille uniquement sur le projet) sur la façon dont j'ai "groupé" mon code. J'ai essayé de tout diviser de telle manière qu'il supprime autant que possible les dépendances.

J'essaie de le garder aussi découplé que possible, donc en 12 mois, lorsque mon temps est écoulé, quiconque arrive ne peut avoir aucun problème à étendre ce que j'ai produit.

Exemple de structure:

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)

(Remarque: les dossiers Modules, Config, Layouts et ZendExtended sont dupliqués dans chaque dossier d'application; mais je les ai omis car ils ne sont pas requis pour mes besoins.)

Pour la bibliothèque, il contient tout le code "universel". Le framework Zend est au cœur de toutes les applications, mais je voulais que ma logique métier soit indépendante du framework Zend. Toutes les interfaces de modèle et de mappeur n'ont pas de références publiques à Zend_Db, mais s'enroulent autour de lui en privé.

Donc, j'espère qu'à l'avenir je serai en mesure de réécrire les mappeurs et les dbtables (contenant un Models_DbTable_Abstract qui étend Zend_Db_Table_Abstract) afin de découpler ma logique métier du framework Zend si je veux déplacer ma logique métier (services) vers un environnement de framework non-Zend (peut-être un autre framework PHP).

En utilisant un serviceLocator et en enregistrant les services requis dans le bootstrap de chaque application, je peux utiliser différentes versions du même service en fonction de la demande et de l'application à laquelle on accède.

Exemple: toutes les applications externes auront un service_auth_External mise en œuvre service_auth_Interface enregistré.

Même chose avec les applications internes avec Service_Auth_Internal implémentant service_auth_Interface Service_Locator :: getService ('Auth').

Je crains de manquer certains problèmes possibles avec cela.

Celui que je pense à moitié est un fichier config.ini pour tous les externes, puis une application distincte config.ini remplaçant ou ajoutant au config.ini externe global.

Si quelqu'un a des suggestions, je serais très reconnaissant.

J'ai utilisé la commutation de contextes pour les fonctions AJAX dans les applications individuelles, mais il y a de grandes chances que les services externes et internes obtiennent des services Web créés pour eux. Encore une fois, ceux-ci seront séparés en raison de l'autorisation et des différents services disponibles.

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

En fin de compte, certains codes seront spécifiques à la «logique métier» de votre application, et certains sont des «codes de bibliothèque». Par exemple, quelque chose qui valide la saisie d'un formulaire peut généralement être considéré comme une «bibliothèque», alors que quelque chose qui vous aide à calculer les offres disponibles pour le client X au cours d'un mois donné est clairement une «logique métier».

Il s'agit davantage d'un problème de contrôle de version, et il existe de nombreuses façons de dépouiller ce chat en particulier. Des outils comme Maven (et dans une certaine mesure Phing / Ant) sont conçus pour assembler des applications à partir de sources diverses et disparates - basées sur une sorte de fichier de configuration externe (généralement XML). Cela signifie que vous pouvez gérer des référentiels séparés pour le code de bibliothèque et l'importer dans Application X si vous en avez besoin.

Si vous avez le contrôle sur votre hôte, vous pouvez penser à déplacer des éléments de bibliothèque dans le chemin d'inclusion - et à le conserver en tant que projet à long terme distinct.