Où placer les choses spécifiques à la technologie dans le modèle de domaine?

Question

Nous avons une application qui, avec beaucoup de choses, fait quelques changements à Active Directory (ajouter / supprimer l'utilisateur du groupe, le changement des valeurs d'attribut sur l'utilisateur, etc.).

Nous sommes en train de redessiner elle (de « spaghetti-code » dans une solution plus en couches). Les fonctions de gestion Active Directory est quelque chose que nous aimerions faire abstraction sur une certaine mesure dans la couche de domaine, mais en même temps, la plupart des fonctions sont très dépendantes de la technologie.

Faut-il placer tout le code d'accès Active Directory dans la couche d'accès aux données ainsi que notre DB d'accès, ou est-il autorisé à créer une bibliothèque de répertoire actif de fonctions et d'appeler dans cette bibliothèque directement à partir du modèle de domaine? Cela fait l'objet de domaine persistant conscient et est probablement une mauvaise idée?

Ou doit tout accès à Active Directory au lieu être effectuée dans la couche de service au lieu et même pas impliquer la couche de domaine?

Answer 1

Modèles de domaine doivent être technologie agnostique , alors ne mettez pas votre code AD dans le modèle de domaine.

En substance, on peut dire que le code AD est une autre forme de données Access, il appartient à l'accès aux données couche (DAL). Cependant, il ne fait pas partie avec votre module de base de données, car ce serait une violation de la principe de responsabilité unique . (SRP - il applique aux modules ainsi que les types individuels)

Au lieu de la vente liée avec l'accès à la base, la mettre en œuvre dans sa propre bibliothèque. Conceptuellement, il appartient à la même couche, mais il fait des choses différentes, alors maintenant vous avez deux bibliothèques dans la même couche. C'est tout à fait bien -. Vous pouvez avoir autant de bibliothèques dans chaque couche que vous avez besoin

Dans le modèle de domaine, traiter l'accès AD (et l'accès DB) comme des abstractions. Résumé sont Référentiels l'approche par défaut . La bibliothèque AD contiendra des implémentations du référentiel AD, et la bibliothèque DB contiendra les implémentations des Référentiels DB.

Cela correspond bien Domain-Driven Design et le concept d'un couche anti-corruption .

Vous pouvez utiliser injection de dépendances (DI) pour câbler les Référentiels en béton avec votre modèle de domaine.

Answer 2

Je pense que les choses spécifiques à la technologie sont les détails de mise en œuvre, ne devrait pas être mis dans le modèle de domaine.