Ich habe eine Bankkontodomain wie unten aufgeführt. Es kann SavingsAccount, LoanAccount, FixedAccount usw. geben. Ein Benutzer kann mehrere Konten haben. Ich muss eine neue Funktionalität hinzufügen - alle Konten für einen Benutzer abrufen. Wo und wie soll die Funktion geschrieben werden?

Es wäre großartig, wenn die Lösung den SOLID-Prinzipien (Open-Closed-Prinzip,…) und DDD folgen würde.

Jegliches Refactoring, das den Code verbessern würde, ist willkommen.

Hinweis: Der AccountManipulator wird von einem Website-Client über einen Webdienst verwendet.

namespace BankAccountBL
{
public class AccountManipulator
{
    //Whether it should beprivate or public?
    private IAccount acc;

    public AccountManipulator(int accountNumber)
    {
        acc = AccountFactory.GetAccount(accountNumber);
    }

    public void FreezeAccount()
    {
        acc.Freeze();
    }

}

public interface IAccount
{
    void Freeze();
}

public class AccountFactory
{
    public static IAccount GetAccount(int accountNumber)
    {
        return new SavingsAccount(accountNumber);
    }
}

public class SavingsAccount : IAccount
{
    public SavingsAccount(int accountNumber)
    {

    }

    public void Freeze()
    {

    }
}
}

LESEN:

Wann soll das CQRS-Entwurfsmuster verwendet werden?

Wäre es im domänengetriebenen Design eine Verletzung von DDD, Aufrufe an die Repostiorien anderer Objekte in einem Domänenobjekt zu senden?

Refactoring der Domänenlogik, die auf Repositorys in einem Legacy-System zugreift

Welches dieser Beispiele steht für die korrekte Verwendung von DDD?

Gute domänengetriebene Designbeispiele

Vorteil der Erstellung eines generischen Repositorys gegenüber einem spezifischen Repository für jedes Objekt?