Modèle de domaine anémique: Avantages / inconvénients

Question

J'aimerais savoir quels sont les avantages et les inconvénients de l'utilisation d'un modèle de domaine anémique (voir le lien ci-dessous).

Article de Fowler

Answer 1

Avec "Anémique Modèle de Domaine" être anti-modèle, pourquoi sont-ils si nombreux systèmes de mise en œuvre de cette?

Je pense qu'il y a plusieurs raisons

1. La complexité du système

Dans un système simple (ce qui est presque tous les exemples et les exemples de code que vous trouverez sur internet) si je veux mettre en place:

L'ajout de produit à l'Ordre

J'ai mis cette fonction sur la Commande

public void Order.AddOrderLine(Product product)
{
    OrderLines.Add(new OrderLine(product));
}

Sympa et super orientée objet.

Maintenant, disons que j'ai besoin de faire en sorte que j'ai besoin de valider que le produit existe dans l'inventaire et lancer une exception si il ne le fait pas.

Je ne peux pas vraiment le mettre sur Ordre plus, car je ne veux pas que ma commande soit dépendante de l'Inventaire, alors maintenant, il faut aller sur le service

public void OrderService.AddOrderLine(Order order, Product product)
{
    if (!InventoryService.Has(product)
       throw new AddProductException

    order.AddOrderLine(product);
}

Je pourrais aussi passer IInventoryService à l'Ordre.AddOrderLine, qui est une autre option, mais qui fait toujours de l'Ordre dépend de InventoryService.

Il y a encore certaines fonctionnalités dans l'Ordre.AddOrderLine, mais généralement, il est limité à l'Ordre de la portée, alors que dans mon expérience, il est beaucoup plus Logique d'Entreprise hors de portée.

Lorsque le système est plus juste CRUD de base, vous allez vous retrouver avec la plupart de votre logique en OrderService et très peu dans l'Ordre.

2. Développeur de vue de la programmation orientée objet

Il y a beaucoup de discussions enflammées sur l'internet à propos de laquelle la logique devrait aller sur des entités.

Quelque chose comme

Ordre.Enregistrer

Devrait Afin de savoir comment sauver lui-même ou pas? Disons que nous avons des référentiels pour que.

Maintenant pouvez Commander ajouter des lignes de commande? Si j'essaie de donner un sens à l'aide d'un anglais simple, il n'a pas vraiment de sens. L'utilisateur ajoute des Produits à la Commande, de sorte que devons-nous faire de l'Utilisateur.AddOrderLineToOrder()? Qui semble exagéré.

Que diriez-OrderService.AddOrderLine(). Maintenant, il fait un peu de sens!

Ma compréhension de la programmation orientée objet, c'est que pour l'encapsulation de vous mettre des fonctions sur les classes où la fonction aurez besoin pour accéder à la classe interne de l'état. Si j'ai besoin d'accéder à l'Ordre.OrderLines collection, j'ai mis de l'Ordre.AddOrderLine() sur Commande. De cette façon, la classe interne de l'état n'est pas exposés.

3. Cio Des Conteneurs

Les systèmes qui utilisent des Cio conteneurs sont généralement totalement anémique.

C'est parce que vous pouvez tester vos services/référentiels qui ont des interfaces, mais ne peut pas tester des objets du domaine (facilement), sauf si vous les mettez sur toutes les interfaces.

Depuis "Cio", est actuellement considéré comme étant la solution pour tous vos problèmes de programmation, beaucoup de gens suivent aveuglément et de cette façon jusqu'à la fin avec Anémique Modèles de Domaine.

4. La POO est dur, la procédure est facile

J'ai un peu un "Malédiction de la Connaissance" sur ce point, mais j'ai découvert que pour les nouveaux développeurs ayant Otd et des Services est beaucoup plus facile que le Riche Domaine.

Probablement, c'est parce qu'avec le Riche Domaine, il est plus difficile de savoir sur quelles classes pour mettre de la logique. Quand à créer de nouvelles classes? Les modèles à utiliser? etc..

Avec apatrides services, vous pouvez claque dans le service avec nom le plus proche.

Answer 2

Les avantages:

• Vous pouvez demander, c'est un modèle de domaine et de se vanter à vos amis développeur et le mettre sur votre cv.
• Il est facile de générer automatiquement à partir de tables de base de données.
• Elle correspond à des Objets de Transfert de Données étonnamment bien.

Les inconvénients:

• Votre domaine logique existe quelque part autre chose, probablement dans une classe pleine d' classe(statique) des méthodes. Ou de votre interface code. Ou dans plusieurs endroits, le tout avec logique en conflit.
• C'est un anti-modèle, de sorte que les autres les développeurs vont vous demander si vous comprendre les concepts de l'objet conception orientée.

Answer 3

Suite à cela, il y a eu une pensée dans ma tête pendant un temps très long maintenant. Il est ma conviction que le terme de "programmation orientée objet" a pris un sens pas vraiment prévu pour cela. L'anagramme signifie "programmation orientée objet", comme nous le savons tous. Bien sûr, le centre est sur le mot "orientée". Il n'est pas "OMP", qui signifie "objet de mandat de programmation". Les deux SMA et RDM sont des exemples de la programmation orientée objet. Ils font usage de l'objet, les propriétés, les méthodes des interfaces et ainsi de suite. Cependant, il y a une différence entre le SMA et de la RDM dans la façon dont nous choisissons de encapulate choses. Ils sont deux choses différentes. Dire que le SMA est mauvais de la POO n'est pas une déclaration exacte. Peut-être que nous avons besoin de différents termes pour vaious niveaux d'encapsulation à la place. En outre, je n'ai jamais aimé le terme anti-modèle. Il est généralement attribué à quelque chose par des membres d'un groupe adverse. Les deux SMA et RDM sont valables motif, ils ont simplement ont des objectifs différents à l'esprit, et sont destinées à résoudre les différents besoins de l'entreprise. Ceux d'entre nous qui pratique DDD devrait, à tout le moins, d'apprécier le présent, et de ne pas baisser le niveau des autres par le dénigrement de ceux qui choisissent de mettre en œuvre des ADM. Juste mes pensées.

Answer 4

Il me semble que Fowler principale objection est que les Sma ne sont pas OO, dans le sens suivant. Si l'on conçoit un système de "partir de zéro" autour passive des structures de données qui sont manipulées par d'autres morceaux de code, alors c'est certainement sent plus comme la conception procédurale de conception orientée objet.

Je suggère qu'il y a au moins deux forces qui peuvent produire ce type de conception:

1. Concepteurs/développeurs qui pensent encore sur le plan procédural être appelés à travailler dans un orientée objet (en supposant qu'ils peuvent...) pour produire un nouveau système, et

2. Les développeurs travaillent pour mettre un service comme le "visage" sur un héritage du système conçu dans un non-OO mode (quelle que soit la langue).

Si, par exemple, ont été la construction d'un ensemble de services pour exposer les fonctionnalités d'une application mainframe COBOL, on pourrait définir les services et les interfaces en termes d'un modèle conceptuel qui n'est pas le miroir de l'intérieur COBOL structures de données. Toutefois, si le service de cartes le nouveau modèle de l'héritage utilisation des données existantes-mais-caché de la mise en œuvre, puis le nouveau modèle pourrait très bien être "anémique", dans le sens de Fowler de l'article -- par exemple, un ensemble de TransferObject-les définitions de style et les relations avec pas de réel problème.

Ce type de compromis peut très bien être commun pour les limites à ce qui dans l'idéal-pure OO des systèmes d'interagir avec les non-OO environnement.