DDD und Konfiguration

Question

Wie gebe ich Zugriff auf Benutzer konfiguriert Einstellungen in DDD?

Wir haben eine Konfigurationsdatenbank, die Elemente als eine Reihe von Schlüssel-Wert-Paaren speichert. Dies scheint nicht wirklich zum Repository-Muster zu passen. Wie kann ich dem Benutzer den Zugriff auf diese Konfigurationswerte ermöglichen?

Idealerweise würde ich gerne separate Klassen für verschiedene Gruppierungen der Konfiguration haben, dh .. BillingSettings, ReportSettings, TaxSettings.

Es wäre seltsam, ein separates Repository für jede von diesen bereitzustellen, aber ich möchte auch Persistenz Ignoranz für diese Einstellungen Klassen beibehalten.

Wie kann der Zugriff auf die Konfiguration in DDD korrekt aktiviert werden?

Answer 1

Was ich normalerweise tun, ist nur die Konfiguration mit Schnittstellen abstrahieren, z. IBillingConfiguration, IReportConfiguration usw. Die Implementierungen von diesen sind dann, was in die relevanten Methoden (oder in die relevanten Objekte injiziert) gelangt.

Woher die Werte kommen, sollte dann eigentlich egal sein. Es gibt Zeiten, in denen ich ein Repository verwende, um die Werte in einer Datenbank zu speichern, und dann hätte ich etwas wie IConfigurationPropertyRepository. Es ist etwas peinlich, da sich ein ConfiruationProperty nicht wirklich wie ein erstklassiger Bürger in der Entity Welt fühlt, aber es scheint, dass die Arbeit erledigt wird.

Ich würde einige Implementierung eines IBillingConfiguration, dass nur die erforderliche Eigenschaft aus einer zugrunde liegenden Sammlung oder ConfigurationProperty Objekte zurückgibt.

Die entsprechenden Get und Save Methoden für jede I{Some}Configuration würde auf dem so ConfigurationPropertyRepository umgesetzt werden, dass ich/speichern nur diese Teilmenge der Eigenschaften, die angewendet werden müssen.

Answer 2

Ist BillingSettings tatsächlich ein Aggregat (oder sogar ein Domänenobjekt) in Ihren Domänenmodellen? Wenn nicht, sollte es kein entsprechendes Repository haben.

Die meisten Konfigurationen sind infrastrukturspezifisch wie jdbc URL, Passwort und so weiter. Sie müssen nicht mit DDD umgehen. Wir benötigen möglicherweise einen ConfigurationService, der CRUD-Operationen unterstützt, wenn die Einstellungen in der Datenbank gespeichert sind und von Benutzern zur Laufzeit geändert werden dürfen. Der ConfigurationService gehört jedoch nicht zur Domäne und diesem beschränkten Kontext, sondern ist lediglich ein Infrastrukturdienst. Wir müssen es nicht auf DDD-Basis entwickeln.

Update für @Kristof Jozsa Kommentar.

Die Einstellungen werden verwendet, um ein Domänenkonzept zu unterstützen. Das Domänenkonzept ist abstrakt und der Zugriff auf Einstellungen ist eine Implementierungsdetails.

class ExpirationSpecification { 
    private int days 
    //other settings?   

    public ExpirationSpecification(int days) {...} 

    public boolean isSatisfied(Order order) {...} 
} 

public class ExpirationServiceImpl implements ExpirationService { 
    //private int days;//inject using placeholder in spring 
    private ConfigurationService configService;//if settings are stored in database 

    ExpirationSpecification spec() { 
     //return new ExpirationSpecification(days); 
     return new ExpirationSpecification(configService.orderExpirationDays()); 
    } 

    void cancel(Order order) {...} 
}