Organización de múltiples códigos de aplicación Zend

Durante el año pasado, he estado trabajando en una serie de aplicaciones, todas basadas en el marco Zend y centradas en una lógica empresarial compleja a la que todas las aplicaciones deben tener acceso, incluso si no usan todas (más fácil que tener múltiples carpetas de biblioteca para cada una). aplicación ya que están todos unidos con un centro común).

Sin entrar en muchos detalles sobre de qué trata específicamente el proyecto, estoy buscando información (ya que estoy trabajando solo en el proyecto) sobre cómo he "agrupado" mi código. He tratado de dividirlo todo de tal manera que elimine las dependencias tanto como sea posible.

Estoy tratando de mantenerlo tan desacoplado como pueda lógicamente, por lo que en 12 meses, cuando se acabe el tiempo, cualquier otra persona que ingrese no tendrá problemas para extender lo que he producido.

Estructura de ejemplo:

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: las carpetas Módulos, Configuración, Diseños y ZendExtended están duplicadas en cada carpeta de la aplicación; pero las he omitido ya que no son necesarias para mis fines).

Para la biblioteca, esto contiene todo el código "universal". El marco Zend está en el corazón de todas las aplicaciones, pero quería que mi lógica de negocios fuera independiente del marco Zend. Todas las interfaces de modelo y mapeador no tienen referencias públicas a Zend_Db, pero en realidad lo envuelven en privado.

Entonces, espero que en el futuro pueda reescribir los mapeadores y las tablas de datos (que contienen un Models_DbTable_Abstract que extiende Zend_Db_Table_Abstract) para desacoplar mi lógica de negocios del marco de trabajo de Zend si quiero mover mi lógica de negocios (servicios) a un entorno de marco no Zend (tal vez algún otro marco PHP).

Utilizando un serviceLocator y registrando los servicios requeridos dentro del arranque de cada aplicación, puedo usar diferentes versiones del mismo servicio dependiendo de la solicitud y a qué aplicación se está accediendo.

Ejemplo: todas las aplicaciones externas tendrán un service_auth_External implementando service_auth_Interface registrado.

Lo mismo con las aplicaciones internas con Service_Auth_Internal implementando service_auth_Interface Service_Locator :: getService ('Auth').

Me preocupa que pueda estar perdiendo algunos posibles problemas con esto.

Estoy pensando a medias en un archivo config.ini para todos los externos, luego una aplicación separada config.ini que anula o agrega al config.ini externo global.

Si alguien tiene alguna sugerencia, le agradecería mucho.

He utilizado el cambio de contexto para funciones AJAX dentro de las aplicaciones individuales, pero existe una gran posibilidad de que tanto externos como internos obtengan servicios web creados para ellos. Nuevamente, estos se separarán debido a la autorización y los diferentes servicios disponibles.

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

En última instancia, algunos códigos serán específicos de la "lógica de negocios" de su aplicación, y otros son "códigos de biblioteca". Por ejemplo, algo que valida la entrada del formulario generalmente puede considerarse como "biblioteca", mientras que algo que lo ayuda a calcular las ofertas disponibles para el cliente X en un mes determinado es claramente "lógica de negocios".

Esto es más un problema de control de versiones, y hay muchas maneras en que puedes pelar este gato en particular. Herramientas como Maven (y hasta cierto punto Phing / Ant) están diseñadas para ensamblar aplicaciones de varias fuentes dispares , basadas en algún tipo de archivo de configuración externo (generalmente XML). Esto significa que puede mantener repositorios separados para el código de la biblioteca e importarlo a la Aplicación X si lo necesita.

Si tiene control sobre su host, entonces podría pensar en mover cosas de la biblioteca a la ruta de inclusión y mantenerlo como un proyecto separado a largo plazo.