Wie wende ich einige Konzepte von DDD auf tatsächlichen Code an? Spezifische Fragen im Inneren

Ich habe DDD studiert und habe derzeit Schwierigkeiten, einen Weg zu finden, die Konzepte im tatsächlichen Code anzuwenden. Ich habe ungefähr 10 Jahre Erfahrung mit N-Tier, daher ist es sehr wahrscheinlich, dass ich Probleme habe, weil mein mentales Modell zu sehr an dieses Design gekoppelt ist.

Ich habe eine Asp.NET-Webanwendung erstellt und beginne mit einer einfachen Domäne: einer Webüberwachungsanwendung. Bedarf:

• Der Benutzer muss in der Lage sein, eine neue zu überwachende Webanwendung zu registrieren. Die Web-App hat einen Anzeigenamen und verweist auf eine URL.
• Die Web-App fragt regelmäßig nach einem Status (online / offline).
• Die Web-App fragt regelmäßig nach ihrer aktuellen Version (es wird erwartet, dass die Web-App eine "/version.html" hat, eine Datei, die ihre Systemversion in einem bestimmten Markup deklariert).

Meine Zweifel betreffen hauptsächlich die Aufteilung der Verantwortlichkeiten, die Suche nach dem richtigen Ort für jede Sache (Validierung, Geschäftsregel usw.). Unten habe ich Code geschrieben und Kommentare mit Fragen und Überlegungen hinzugefügt.

Bitte kritisieren und beraten . Danke im Voraus!

DOMAIN-MODELL

Modelliert, um alle Geschäftsregeln zu kapseln.

// Encapsulates logic for creating and validating Url's.
// Based on "Unbreakable Domain Models", YouTube talk from Mathias Verraes
// See https://youtu.be/ZJ63ltuwMaE
public class Url: ValueObject
{
    private System.Uri _uri;

    public string Url => _uri.ToString();

    public Url(string url)
    {
        _uri = new Uri(url, UriKind.Absolute); // Fails for a malformed URL.
    }
}

// Base class for all Aggregates (root or not).
public abstract class Aggregate
{
    public Guid Id { get; protected set; } = Guid.NewGuid();
    public DateTime CreatedAt { get; protected set; } = DateTime.UtcNow;
}

public class WebApp: Aggregate
{
    public string Name { get; private set; }
    public Url Url { get; private set; }
    public string Version { get; private set; }
    public DateTime? VersionLatestCheck { get; private set; }
    public bool IsAlive { get; private set; }
    public DateTime? IsAliveLatestCheck { get; private set; }

    public WebApp(Guid id, string name, Url url)
    {
        if (/* some business validation fails */)
            throw new InvalidWebAppException(); // Custom exception.

        Id = id;
        Name = name;
        Url = url;
    }

    public void UpdateVersion()
    {
        // Delegates the plumbing of HTTP requests and markup-parsing to infrastructure.
        var versionChecker = Container.Get<IVersionChecker>();
        var version = versionChecker.GetCurrentVersion(this.Url);

        if (version != this.Version)
        {
            var evt = new WebAppVersionUpdated(
                this.Id, 
                this.Name, 
                this.Version /* old version */, 
                version /* new version */);
            this.Version = version;
            this.VersionLatestCheck = DateTime.UtcNow;

            // Now this eems very, very wrong!
            var repository = Container.Get<IWebAppRepository>();
            var updateResult = repository.Update(this);
            if (!updateResult.OK) throw new Exception(updateResult.Errors.ToString());

            _eventDispatcher.Publish(evt);
        }

        /*
         * I feel that the aggregate should be responsible for checking and updating its
         * version, but it seems very wrong to access a Global Container and create the
         * necessary instances this way. Dependency injection should occur via the
         * constructor, and making the aggregate depend on infrastructure also seems wrong.
         * 
         * But if I move such methods to WebAppService, I'm making the aggregate
         * anaemic; It will become just a simple bag of getters and setters.
         *
         * Please advise.
         */
    }

    public void UpdateIsAlive()
    {
        // Code very similar to UpdateVersion().
    }
}

Und eine DomainService-Klasse für das Erstellen und Löschen, von der ich glaube, dass sie nicht das Aggregat selbst betrifft.

public class WebAppService
{
    private readonly IWebAppRepository _repository;
    private readonly IUnitOfWork _unitOfWork;
    private readonly IEventDispatcher _eventDispatcher;

    public WebAppService(
        IWebAppRepository repository, 
        IUnitOfWork unitOfWork, 
        IEventDispatcher eventDispatcher
    ) {
        _repository = repository;
        _unitOfWork = unitOfWork;
        _eventDispatcher = eventDispatcher;
    }

    public OperationResult RegisterWebApp(NewWebAppDto newWebApp)
    {
        var webApp = new WebApp(newWebApp);

        var addResult = _repository.Add(webApp);
        if (!addResult.OK) return addResult.Errors;

        var commitResult = _unitOfWork.Commit();
        if (!commitResult.OK) return commitResult.Errors;

        _eventDispatcher.Publish(new WebAppRegistered(webApp.Id, webApp.Name, webApp.Url);
        return OperationResult.Success;
    }

    public OperationResult RemoveWebApp(Guid webAppId)
    {
        var removeResult = _repository.Remove(webAppId);
        if (!removeResult) return removeResult.Errors;

        _eventDispatcher.Publish(new WebAppRemoved(webAppId);
        return OperationResult.Success;
    }
}

ANWENDUNGSSCHICHT

Die folgende Klasse bietet eine Schnittstelle für die WebMonitoring-Domäne zur Außenwelt (Webschnittstellen, Rest-APIs usw.). Momentan ist es nur eine Shell, die Anrufe an die entsprechenden Dienste umleitet, aber es würde in Zukunft wachsen, um mehr Logik zu orchestrieren (immer über Domänenmodelle).

public class WebMonitoringAppService
{
    private readonly IWebAppQueries _webAppQueries;
    private readonly WebAppService _webAppService;

    /*
     * I'm not exactly reaching for CQRS here, but I like the idea of having a
     * separate class for handling queries right from the beginning, since it will
     * help me fine-tune them as needed, and always keep a clean separation between
     * crud-like queries (needed for domain business rules) and the ones for serving
     * the outside-world.
     */

    public WebMonitoringAppService(
        IWebAppQueries webAppQueries, 
        WebAppService webAppService
    ) {
        _webAppQueries = webAppQueries;
        _webAppService = webAppService;
    }

    public WebAppDetailsDto GetDetails(Guid webAppId)
    {
        return _webAppQueries.GetDetails(webAppId);
    }

    public List<WebAppDetailsDto> ListWebApps()
    {
        return _webAppQueries.ListWebApps(webAppId);
    }

    public OperationResult RegisterWebApp(NewWebAppDto newWebApp)
    {
        return _webAppService.RegisterWebApp(newWebApp);
    }

    public OperationResult RemoveWebApp(Guid webAppId)
    {
        return _webAppService.RemoveWebApp(newWebApp);
    }
}

Die Sache schließen

Nachdem ich hier und in dieser anderen Frage , die ich aus einem anderen Grund geöffnet hatte, aber letztendlich den gleichen Punkt wie diese erreicht hatte, Antworten gesammelt hatte , kam ich zu dieser saubereren und besseren Lösung:

Lösungsvorschlag in Github Gist

Nach langen Ratschlägen zu Ihrem WebAppAggregat stimme ich voll und ganz zu, dass repositoryes hier nicht der richtige Ansatz ist, das zu ziehen. Nach meiner Erfahrung wird das Aggregat die "Entscheidung" treffen, ob eine Aktion in Ordnung ist oder nicht, basierend auf ihrem eigenen Zustand. Somit nicht auf Zustand kann es von anderen Diensten ziehen. Wenn Sie eine solche Prüfung benötigen würden, würde ich diese im Allgemeinen auf den Dienst verschieben, der das Aggregat aufruft (in Ihrem Beispiel die WebAppService).

Darüber hinaus können Sie auf den Anwendungsfall stoßen, dass mehrere Anwendungen gleichzeitig Ihr Aggregat aufrufen möchten. Wenn dies passieren würde, während Sie ausgehende Anrufe wie diese tätigen, was lange dauern kann, blockieren Sie Ihr Aggregat für andere Verwendungen. Dies würde schließlich die Handhabung von Aggregaten verlangsamen, was meiner Meinung nach auch nicht wünschenswert ist.

Obwohl es den Anschein hat, dass Ihr Aggregat ziemlich dünn wird, wenn Sie dieses Validierungselement verschieben, denke ich, dass es besser ist, es auf das zu verschieben WebAppService.

Ich würde auch vorschlagen, die Veröffentlichung des WebAppRegisteredEreignisses in Ihr Aggregat zu verschieben. Das Aggregat ist der Typ, der erstellt wird. Wenn der Erstellungsprozess erfolgreich ist, ist es sinnvoll, dieses Wissen in der Welt veröffentlichen zu lassen.

Hoffe das hilft dir @Levidad!