Faire face à un modèle de domaine anémique

Question

J'essayais de séparer mon DAL de mon Couche Métier et, ce faisant, j'ai décidé d'éviter toute approche ActiveRecord et d'adopter une approche DataMapper. En d'autres termes, les objets de mon domaine ne prendraient pas soin de leur propre persistance. Ce faisant, je semble empiéter sur l'anti-pattern «anemic domain model». Par exemple, l'une des entités de mon programme est une organisation.

Une organisation est représentée comme quelque chose comme ceci:

class Organization { 
    private $orgId; 
    private $orgName; 

    // getters and setters 
} 

Donc, fondamentalement, cette organisation ne fait rien d'autre que d'agir comme « sac » (comme Martin Fowler dit) pour certaines données. Dans le monde PHP, ce n'est rien de plus qu'un tableau glorifié. Il n'y a aucun comportement associé.

Et le comportement dans le programme, j'ai été coller dans la classe "niveau de service" comme un OrganizationService qui sert principalement d'intermédiaire entre ces objets et le DAL.

Outre les problèmes de mise à l'échelle potentiels avec PHP (j'ai d'autres raisons pour lesquelles j'insiste pour «mettre en sac» mes données dans ces objets), cette approche est-elle totalement désactivée?

Comment gérez-vous vos modèles de domaine dans ces situations? Peut-être qu'une organisation ne fait pas partie de mon domaine en premier lieu?

Answer 1

bien, il semble que cela au début, mais quand vous Refactor votre code plus, vous aurez à un comportement pour votre classe organisation ...

un exemple que je pourrais penser maintenant Si vous avez des employés, vous voudrez peut-être les associer à l'organisation. Ainsi, vous pourriez avoir une méthode AssociateEmployee(User employee) qui pourrait trouver sa place dans votre classe d'organisation.

Ou vous pourriez changer d'emplacement de la société, au lieu de définir des paramètres tels que l'adresse, ville, état en trois étapes, vous pouvez ajouter la méthode ChangeLocation(Street, City, State) ..

Il suffit d'aller étape par étape, lorsque vous rencontrez un certain code BL/couche de service qui semble appartenir au domaine, déplacez-la vers le domaine. Si vous lisez Fowler, vous l'obtiendrez très bientôt quand vous le verrez dans votre code.

Answer 2

Il pourrait juste être anémique maintenant? Par exemple, une fois que je développais un site d'inscription à une réunion/à une conférence. Cela a commencé avec une seule réunion. Il y avait encore une classe de réunion et une seule instance, mais l'année suivante, nous avons tenu la conférence, elle a été étendue et de nouvelles propriétés ont été ajoutées (pour tenir deux réunions consécutives), donc clairement, c'était tout simplement pas complètement développé, car nous avons ensuite ajouté des groupes de réunions qui pouvaient contenir plusieurs réunions. Donc, je pense qu'il est important de garder à l'esprit que les domaines changent avec le temps et que votre modèle peut finir par être refactorisé, donc même si vous pensez qu'il est anémique, il peut être un peu trop tourné vers l'avenir (comme votre organisation la classe commencera à avoir des paramètres, des règles ou des préférences ou quelque chose comme ça).

Answer 3

Votre entité n'est pas anémique parce que vous prenez une resposabilité qui ne devrait pas être là pour commencer. Persistance et récupération des entités est la responsabilité des référentiels. Vraiment, votre comportement devrait être dans vos entités et non dans une couche de service. Mais expliquer ce qui se passe bien au-delà de la simple réponse. DDD par Eric Evans est un bon point de départ.

Answer 4

Vous pouvez également considérer que si vous n'avez pas beaucoup de règles métier ou que le domaine n'est pas si complexe, DDD peut être trop lourd pour vous. DDD est une excellente solution pour les grands domaines complexes, mais il y a beaucoup de frais généraux et de complexité si vous faites simplement des données, des données. DDD est plus difficile à concevoir et ajoute intrinsèquement de la complexité, donc pour le justifier, la complexité du problème devrait l'emporter sur cela.

C'est tout ce que j'ajouterais à zappan et epitka.