Yo preguntéesta pregunta Hace un tiempo, pero ahora estoy buscando implementar una separación real entre la capa de acceso a mi base de datos y la capa de dominio. También voy a trabajar para mover la lógica de negocios al dominio al que pertenece y fuera de los scripts del controlador.

Estoy usando Zend Framework que implementa los patrones Table Data Gateway y Row Data Gateway para la capa de acceso a datos, pero aparentemente no define realmente cómo construir una capa de dominio que sea independiente de la capa de acceso a datos. He considerado usar un patrón de Active Record donde la lógica de dominio coexiste con la lógica de acceso a datos, pero tengo la siguiente situación que ocurre al menos una vez que no creo que Active Record maneje:

Tengo una sola tabla "Persona" que contiene los campos person_id y userType.

Cada tipo de usuario (administrador, comprador, asociado, supervisor) tiene una lógica comercial específica asociada y todos los tipos heredan algunas funciones básicas de un objeto Persona.

No quiero inflar el objeto Row Data Gateway con lógica empresarial que pertenece específicamente a un solo tipo de usuario, pero no estoy seguro de cómo construir la capa de dominio para representar los diferentes tipos de usuarios. Por ejemplo, ¿hago un objeto Person que contenga el objeto PersonGateway y luego escribo funciones de contenedor que pasan llamadas al objeto gateway, o escribo el objeto Person para extender el objeto PersonGateway y luego solo implemento las funciones específicas que necesito?

Del mismo modo, normalmente pensaría que este es (en parte) un problema de fábrica donde necesito un método de fábrica que instanciará la subclase correcta basada en userType. ¿Sigue siendo el mejor método aquí con la clase Zend_Db de Zend Framework?

Cualquier sugerencia o enlace a tutoriales que hablen sobre cómo crear correctamente un modelo de dominio sobre Zend_Db sería muy apreciada.