Qu'est-ce qu'un moyen pratique de modéliser les tables de recherche dans Domain Driven Design (DDD)?

Question

Je suis en train d'apprendre le DDD (Eric Evans livre est ouvert en face de moi) et j'ai rencontré un problème que je ne peux pas trouver une réponse. Que faites-vous dans DDD, quand vous êtes juste essayer d'obtenir une simple liste de recherche les enregistrements?

Ex.

EmployeeID: 123
EmployeeName: John Doe
État: Alaska (liste déroulante)
Comté: Wasilla (liste déroulante -- seront filtrés en fonction de l'état).

Par exemple, disons que vous avez un Employé de domaine objet, un IEmployeeRepository interface et un EmployeeRepository classe. Il sera utilisé par une INTERFACE utilisateur pour afficher une liste des employés et les détails individuels. Dans l'INTERFACE utilisateur, vous souhaitez utiliser une liste déroulante pour l'Etat et la région où vit l'employé. La Disposition des comtés seront filtrés en fonction de l'état qui a été choisi.

Malheureusement, les tables de base de données et l'INTERFACE utilisateur sont très différentes. Dans tblEmployees, il contient le Code de l'État=AK et le Comté de Code=02130, pas de l'État et du Comté de Noms.

À l'ancienne (avant que j'ai commencé cette DDD quête) serait assez simple, il suffit de créer 2 requêtes et l'utilisation d'un DataReader pour remplir les menus déroulants. En dessous de l'écran dans le menu déroulant " est la valeur, qui est automatiquement utilisé dans la forme de messages.

Avec DDD, si je ne suis pas sûr de savoir comment vous êtes censé le faire. J'ai d'abord commencé par la création de l'État et le Comté d'objets référentiels et des interfaces pour les dépôts. Toutefois, l'écriture 4 classes + 2 interfaces et de la plomberie dans la hbm.xml les fichiers de + Employé Business objects semble exagéré, juste 2 requêtes pour 2 menus déroulants. Il y a une meilleure façon, n'est-ce pas? Je ne suis pas en changeant les dossiers dans l'État ou du Comté de tables de si tôt et même si je l'ai fait, il ne serait pas grâce à cette application. Donc je n'ai pas vraiment envie de créer des objets métier de l'État et du Comté si je n'ai pas d'.

La solution la plus simple que je vois, c'est de créer un helper classe avec des méthodes qui retournent des dictionnaires, comme GetStatesAll(), GetState() et GetCounties() et GetCounty(), mais qui se sent juste mal un DDD point de vue.

S'il vous plaît aider. Comment puis-je utiliser DDD sans overengineering juste un couple de simples recherches?

La Solution Finale Je pense que j'ai finalement trouvé ma réponse grâce à l'expérience, qui était de mettre le GetStates() la méthode dans son propre Accès aux Données de la classe, mais pas une classe de référentiel. Depuis que je ne faisais que l'accès en lecture seule, je l'ai jeté dans une struct DTO. Depuis la base de données était petite, j'ai jeté au total dans une classe unique, comme Todd décrit ci-dessous.

Mes conclusions:

1. Les tables de recherche ne sont JAMAIS des objets de valeur, parce que les tables de recherche de TOUJOURS avoir une identité. Si ils n'ont pas d'identité, vous finiriez par avoir des doublons, ce qui ne serait pas beaucoup de sens.
2. Lecture seule table de recherche peut avoir un référentiel, mais sans doute n'en a pas besoin. L'objectif d'un référentiel est de réduire la complexité en forçant l'accès uniquement par le biais de l'agrégat. En passant par le total vous offre un moyen de s'assurer que les règles de gestion peuvent être appliquées, comme par exemple l'ajout de pneus si vous n'avez pas de voiture.
3. Si vous le permettez CRUD de maintenance sur la table de recherche, alors il est logique pour la table de recherche à disposer de son propre référentiel.
4. Le fait que j'ai fini par ranger les codes de structs ne fait pas d'eux "types de valeur". Fowler dit dans POEAA qu'une structure est un type de valeur. C'est vrai, les structures sont immuables, c'est pourquoi Fowler dit qu'ils sont des "types de valeur", cependant, j'ai été de les utiliser différemment. J'ai été en utilisant les structures comme un moyen léger de passer autour des Otd que je n'ai pas de plan sur la modification de l'après leur création. En vérité, les structures que j'ai utilisé n'a, en effet, ont des identités, mais parce qu'ils étaient en lecture seule, ils ont travaillé comme des structures.
5. Un modèle que j'ai utilisé et que je ne vois pas beaucoup d'ailleurs, est de faire des champs de clé primaire être immuable. Ils sont définis par le constructeur, mais ils sont en lecture seule (pas privé accesseurs) et ne peut être modifié une fois que l'objet est créé.

Answer 1

Vous voudrez peut-être chercher dans le concept de Commande de Requête de Séparation. Je ne voudrais pas vous soucier de tapé des référentiels pour les valeurs de recherche, mais je serais encore probablement utiliser DTO type de classes de plus de jeux de données, etc...

Vous pouvez consacrer un peu de temps à la lecture de Greg Young blogs à partir de ce un pour le présent. Il ne parle pas de remplissage de données de recherche en particulier, mais il parle pas de la manipulation de la lecture/la fonctionnalité de reporting de votre demande par le biais de tapé des méthodes sur un référentiel.

Answer 2

En utilisant DDD j'ai quelque chose de similaire avec ce qui suit:

Pays, État et Ville sont des objets de valeur qui proviennent d'une table de recherche dans la base de données.

Answer 3

Eh bien, j'ai lu un article de Mathias Verraes il y a quelques temps de parler de cela ici. Il parle de la Séparation des objets de valeur dans le modèle à partir des concepts qui servent à l'INTERFACE utilisateur.

Citant l'article lorsque l'on a demandé si le modèle des Pays comme des entités ou des objets de valeur:

Il n'y a rien d'intrinsèquement mauvais avec la modélisation des pays comme entités et de les stocker dans la base de données. Mais dans la plupart des cas, que de compliquer à l'excès des choses. Les pays ne changent pas souvent. Lorsqu'un du pays, les changements de nom, il est en fait, à toutes fins pratiques, un de nouveaux pays. Si un pays un jour n'existe plus, vous ne pouvez pas simplement changer toutes les adresses, parce que, éventuellement, le pays a été divisé dans les deux pays.

Il propose une autre approche pour introduire un nouveau concept appelé" AvailableCountry:

Ces pays peuvent être des entités dans une base de données, les enregistrements dans un JSON, ou même simplement d'une liste codée en dur dans votre code. (Qui dépend de la si l'entreprise veut facile d'accès par le biais d'une INTERFACE utilisateur.)

<?php

final class Country
{
    private $countryCode;

    public function __construct($countryCode)
    {
        $this->countryCode = $countryCode;
    }

    public function __toString()
    {
        return $this->countryCode;
    }
}

final class AvailableCountry
{
    private $country;
    private $name;

    public function __construct(Country $country, $name)
    {
        $this->country = $country;
        $this->name = $name;
    }

    /** @return Country */
    public function getCountry()
    {
        return $this->country;
    }

    public function getName()
    {
        return $this->name;
    }

}

final class AvailableCountryRepository
{
    /** @return AvailableCountry[] */
    public function findAll()
    {
        return [
            'BE' => new AvailableCountry(new Country('BE'), 'Belgium'),
            'FR' => new AvailableCountry(new Country('FR'), 'France'),
            //...
        ];
    }

    /** @return AvailableCountry */
    public function findByCountry(Country $country)
    {
        return $this->findAll()[(string) $country];
    }
}

Donc, il semble y avoir une 3ème solution qui consiste à modéliser des tables à la fois comme des objets de valeur et des entités.

BTW, assurez-vous que u vérifier la section des commentaires de certains des discussions sérieuses au sujet de l'article.

Answer 4

Vous êtes en train de lire un mauvais livre si vous voulez apprendre comment faire de l'DDD, sans plus de complication il. :-)

La plus simple solution que vous proposez est très bien si elle répond à vos besoins. L'encapsulation des données d'adresse dans les affaires les objets peuvent être aussi simple ou aussi compliqué que de votre application. Par exemple, l'État de l'objet a un un-à-plusieurs relation avec le Comté Employé vraiment juste besoin de faire référence à un Comté si vous avez choisi le modèle de cette façon. Je tiens seulement à introduire ce genre de complexité, si nécessaire.

En outre, je ne pense pas qu'il y a beaucoup à gagner en définissant des interfaces pour vos dépôts à moins qu'il y a une possibilité réelle que vous pourriez avoir plusieurs référentiels pour vos objets.