1

J'ai une position, et certaines entités qui utilisent la position comme identifiant (géographie, biome, etc.). Si je veux avoir accès à eux, j'aurais besoin de récupérer chacun d'eux par sa position, ce qui provoquerait un code répété. D'un autre côté, je pourrais créer une classe qui est un conteneur, comme un "emplacement". Mais, dans ce cas, pour récupérer la géographie (par exemple), je devrais casser la loi de demeter.Structures de données de domaine contenant des objets de domaine?

Repository.getLocation().getGeography().getHighestPeak(); 

Existe-t-il une autre approche ou un modèle courant qui me manque? Gardez à l'esprit que ce type d'objets (qui se rapportent à la position de la manière que j'ai décrite) sont très susceptibles de grandir en nombre après quelques mois.

+0

Etes-vous sûr que la position est appropriée pour être un ID? Y a-t-il une règle qui garantit qu'il n'y a qu'une seule position pour une entité? – MikeSW

+0

On dirait que votre agrégat racine est trop gros. – jgauffin

Répondre

0

Je ne suis pas sûr que c'est une bonne idée d'avoir un poste d'ID

  • La position d'une entité est susceptible de changer, ce qui conduit à un identifiant instable.

  • Vous ne pourrez pas avoir plusieurs instances d'une entité donnée avec la même position.

D'autre part, je pourrais créer une classe qui est un conteneur, comme un « emplacement ». Mais, dans ce cas, pour récupérer la géographie (par exemple), il faudrait que I casse la loi de demeter.

Repository.getLocation(). GetGeography(). GetHighestPeak();

Vous dites essentiellement qu'un emplacement a une entité, ce qui est un peu gênant. Il semble beaucoup plus naturel de dire qu'une entité a une position. Que diriez-vous de

GeographyRepository.getGeographyByPosition(new Position(...)).getHighestPeak(); 

?

+0

Eh bien, la position d'une géométrie et d'un biome ne changera pas. Ni une ville et ainsi de suite. – user1288851

Questions connexes