Bewegungsrichtung und Leistung

Question

Nehmen wir ein Beispiel, in dem wir zwei Entitäten haben: ServiceProvider und TelephoneNumber. Das System ermöglicht es Dienstanbietern, Telefonnummern hinzuzufügen. Jede von einem Dienstanbieter hinzugefügte Telefonnummer wird durch eine Instanz von TelephoneNumber dargestellt. Also habe ich eine Verbindung zwischen diesen beiden Entitäten. Für den Moment habe ich entschieden, dass eine TelephoneNumber Instanz mit genau einem Dienstanbieter verbunden ist. Ich entschied auch, dass diese zwei Entitäten zum selben Aggregat gehören, wobei ServiceProvider der Gesamtstamm ist (ein Argument ist, dass der TelephoneNumber Lebenszyklus von der ServiceProvider Einheit abhängt).

Meine Frage ist über die Traversierungsrichtung der Assoziation. Ich weiß im Voraus, dass ein Dienstanbieter viele Millionen Telefonnummern hinzufügen kann.

Wenn die Traversierichtung der Assoziation von ServiceProvider zu TelephoneNumber ist, wie kann man effizient implementieren? Das Speichern eines Satzes von Telefonnummern in der Einheit ServiceProvider wäre ineffizient (insbesondere für den Speicher). Lazy Loading kann verwendet werden, aber es würde die Implementierungsoptionen einschränken, indem es Frameworks verwendet, die es unterstützen (z. B. Hibernate).

In einem bekannten Beispiel, wo wir haben Customer und Order Einheiten, eine unidirektionale Assoziation von Order zu Customer wird oft gewählt. Wenn die Durchquerungsrichtung der Zuordnung von TelephoneNumber zu ServiceProvider lautet, wie werden die CRUD-Operationen für TelephoneNumber implementiert? Ich denke, wir müssen eine TelephoneNumberRepository verwenden? Aber ich sah oft, dass Repositories nur für Aggregatwurzeln definiert werden sollten, da wir im Allgemeinen die aggregierte Root-Instanz erhalten und über dieses mit dem Domänenmodell kommunizieren.

Dank

Answer 1

Da Sie Telefonnummern zugreifen müssen nach einigen Kriterien, würde ich nicht eine PhoneNumberRepository zu sehen sogar schockiert, wenn es nicht ein Aggregat Wurzel ist.

Auf der anderen Seite könnten Sie die entsprechenden FindPhoneNumberBy ...() -Methoden direkt in ServiceProvider haben. Was mich stört ist, dass Sie nicht eine große Anzahl von Telefonnummern gleichzeitig im Speicher laden können, was bedeutet, dass Sie in ServiceProvider eine Art von Performance-Management (Lazy Loading/Enumeration, etc.) einführen müssen, um die Trennung von Bedenken zu durchbrechen . Der Vorteil eines separaten Repositorys besteht darin, dass sich die Schnittstelle zwar in der Domäne-Ebene befindet, ihre konkrete Implementierung jedoch in der Infrastruktur-Ebene enthalten ist, was die Verträge der FindPhoneNumberBy ...() -Methoden von den zugrunde liegenden Abruftricks entkoppelt . Alles in allem kann ich keinen legitimeren Kandidaten als ein Repository sehen, um mit solchen Dingen umzugehen.