eu pergunteiessa questão um tempo atrás, mas agora estou procurando implementar uma separação real entre minha camada de acesso ao banco de dados e a camada de domínio. Também vou trabalhar para mover a lógica de negócios para o domínio em que ele pertence e para fora dos scripts do controlador.

Estou usando o Zend Framework, que implementa os padrões Table Data Gateway e Row Data Gateway para a camada de acesso a dados, mas aparentemente falha em realmente definir como criar uma camada de domínio separada da camada de acesso a dados. Eu considerei usar um padrão Active Record em que a lógica do domínio coexiste com a lógica de acesso a dados, mas tenho a seguinte situação que ocorre pelo menos uma vez que não acho que o Active Record manipulará:

Eu tenho uma única tabela "Pessoa" que contém os campos person_id e userType.

Cada userType (administrador, comprador, associado, supervisor) possui uma lógica comercial específica associada a ele e todos os tipos herdam algumas funcionalidades básicas de um objeto Pessoa.

Não quero inchar o objeto Row Data Gateway com lógica comercial que pertence especificamente a apenas um tipo de usuário, mas não sei como construir a camada de domínio para representar os diferentes tipos de usuários. Por exemplo, eu faço um objeto Person que contém o objeto PersonGateway e, em seguida, escrevo funções de wrapper que passam chamadas para o objeto gateway, ou escrevo o objeto Person para estender o objeto PersonGateway e depois implementar apenas as funções específicas necessárias?

Da mesma forma, eu normalmente pensaria que este é (em parte) um problema de fábrica em que preciso de um método de fábrica que instancie a subclasse correta com base no userType. Ainda é o melhor método aqui com a classe Zend_Db do Zend Framework?

Serão muito bem-vindas quaisquer sugestões ou links para tutoriais que falem sobre como criar corretamente um modelo de domínio sobre o Zend_Db.