2017-12-07 5 views
3

Ich stehe vor einem DDD-Design-Problem. Ich bin verwirrt darüber, wie man Repositories mit Aggregaten abgrenzen oder verwenden kann.Design-Repositories, die den DDD-Konzepten folgen

Ich habe derzeit zwei Aggregate TecTacClient und Entitlement.

public class TecTacClient 
{ 
    (...) 
    public ICollection<Entitlement> Entitlements { get; } 
    public bool HasActiveEntitlements => Entitlements.Any(x => x.EndDate >= DateTime.Now); 

    public TecTacClient((...),IEnumerable<Entitlement> entitlements) 
    { 
     (...) 
     Entitlements = new List<Entitlement>(entitlements ?? Enumerable.Empty<Entitlement>()); 
    } 
} 

Ich halte Berechtigung als ein weiteres Aggregat. Es enthält auch eine Sammlung von Berechtigungsdatensätzen. Berechtigungssätze werden unabhängig von Berechtigungen angelegt/aktualisiert. Wenn ich zum Beispiel eine Buchung erstelle, würde ich auch einen Berechtigungssatz erstellen. Diese Operation hat keinen Einfluss auf die Berechtigung.

public abstract class Entitlement : Entity 
{ 
    (...) 

    public ICollection<EntitlementRecord> Records { get; } 

    protected Entitlement((...), IEnumerable<EntitlementRecord> records) 
    { 
     (...) 
     Records = new List<EntitlementRecord>(records ?? Enumerable.Empty<EntitlementRecord>()); 
    } 

    public abstract bool IsEligible(Resource resource); 
    public DateTimeRange GetCoveringPeriod(DateTime date) { ... } 
    public double GetAvailableQuantity(DateTime date) { ... } 
    public void Consume(DateTime date, double quantity) { ... } 
    public void Match(DateTime date, double quantity) { ... } 
    public void Cancel(int bookingId) { ... } 
} 

Ich verstehe, dass Aggregate mithilfe von Repositories abgerufen/beibehalten werden müssen.

Bedeutet das, dass ich zwei Repositorys (für Tectacclient und Berechtigung) erstellen muss und das Berechtigungsrepo im Client-Repo verwenden muss, um Berechtigungen abzurufen?

Soll ich ein anderes Repo für EntitlementRecords erstellen? Ansonsten habe ich am Ende-up einen Anspruch Repo hat, die

IEntitlementRepo 
{ 
    void Create(...); 
    void Update(...); 
    void Delete(...); 

    void AddRecord(...); 
    void DeleteRecord(...); 
} 

Am Ende in der DDD Welt so aussieht muss ich Abhängigkeiten zwischen Repositories einzuführen meine Aggregate abzurufen/beharren?

Antwort

2

Ein Repository pro Aggregat ist eine einfache und gute Lösung, daher ist es besser, einen Repo für Berechtigungen und einen anderen für EntitlementRecords zu haben.

Übrigens sieht Ihr TecTacClient Aggregat nicht gut aus. Normalerweise sollte es keine Berechtigungsaggregate enthalten. Oder die Berechtigung sollte nicht als separates Aggregat betrachtet werden, sie sollte Teil des TecTacClient-Aggregats sein. Dasselbe gilt für EntitlementRecord: Es sollte als Teil des Entitlement-Aggregats betrachtet werden oder Entitlement sollte es nicht enthalten. Lesen Sie mehr über "Design Small Aggregates" -Regel.

+0

Ich dachte, dass eines der Ziele des DDD-Ansatzes darin bestand, Entitäten in einem Aggregat zu gruppieren, um Modelle reicher und Systeme einfacher zu machen. Aber jetzt, nachdem ich diesen Artikel gelesen habe, habe ich das Gefühl, dass Entitäten, die beibehalten werden müssen, ihren eigenen Aggregaten zugeordnet werden müssen. In meiner Situation, durch das Entfernen der Beziehungen zwischen Client, Anspruch und Datensatz habe ich das Gefühl, dass ich zu einem anämischen Design (1 Entität, 1 Aggregat, nicht viel Logik) – Seb

+0

Sie sagen "anemic Design" wie es ist eine schlechte Sache :) Die Designauswahl sollte auf Domänenwissen basieren, daher kann ich diese Auswahl nicht für Sie treffen ... Sehen Sie sich Beispielprojekte an, normalerweise ist Client ein Aggregat und Order mit seinen OrderItems ist ein anderes. Es kann in Ihre Domain übersetzt werden: TecTacClient ist ein Aggregat und Entitlement mit seinen Datensätzen ist ein anderes. Über logis: Meiner Meinung nach sollten Aggregate nicht viel Logik enthalten, nur Logik über die Konsistenz des Aggregats selbst. –

+0

Sehr interessant. Wo speichern Sie die Geschäftslogik, wenn sie nicht aggregiert ist? – Seb

Verwandte Themen