Jak zastosować niektóre pojęcia DDD do rzeczywistego kodu? Szczegółowe pytania w środku

Studiowałem DDD i obecnie staram się znaleźć sposób na zastosowanie tych koncepcji w rzeczywistym kodzie. Mam około 10 lat doświadczenia w warstwie N, więc bardzo prawdopodobne jest, że walczę z tym, że mój model mentalny jest zbyt powiązany z tym projektem.

Stworzyłem aplikację sieci Web Asp.NET i zaczynam od prostej domeny: aplikacji do monitorowania sieci. Wymagania:

• Użytkownik musi mieć możliwość zarejestrowania nowej aplikacji sieci Web do monitorowania. Aplikacja internetowa ma przyjazną nazwę i wskazuje adres URL;
• Aplikacja internetowa będzie okresowo sprawdzać status (online / offline);
• Aplikacja internetowa będzie okresowo sprawdzać aktualną wersję (oczekuje się, że aplikacja będzie mieć plik „/version.html”, który jest plikiem deklarującym swoją wersję systemową w określonym znaczniku).

Moje wątpliwości dotyczą głównie podziału obowiązków, znalezienia odpowiedniego miejsca dla każdej rzeczy (walidacja, zasada biznesowa itp.). Poniżej napisałem kod i dodałem komentarze z pytaniami i uwagami.

Krytykuj i doradzaj . Z góry dziękuję!

MODEL DOMENY

Modelowany w celu zawarcia wszystkich reguł biznesowych.

// 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().
    }
}

I klasa DomainService do obsługi operacji Tworzy i Usuwa, które moim zdaniem nie dotyczą samej Agregacji.

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;
    }
}

WARSTWA STOSOWANIA

Poniższa klasa zapewnia interfejs dla domeny WebMonitoring do świata zewnętrznego (interfejsy sieciowe, pozostałe API itp.). W tej chwili jest to tylko powłoka przekierowująca połączenia do odpowiednich usług, ale w przyszłości będzie rosnąć, aby koordynować więcej logiki (zawsze odbywa się to za pomocą modeli domen).

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);
    }
}

Zamykanie spraw

Po zebraniu odpowiedzi tutaj i na inne pytanie , które otworzyłem z innego powodu, ale ostatecznie dotarłem do tego samego punktu co ten, wymyśliłem to czystsze i lepsze rozwiązanie:

Propozycja rozwiązania w Github Gist

Długie wskazówki dotyczące twojego WebAppagregatu, w pełni zgadzam się z tym, że repositorynie jest tu właściwe podejście. Z mojego doświadczenia wynika, że ​​agregat podejmie „decyzję”, czy działanie jest w porządku, czy nie, na podstawie własnego stanu. W związku z tym nie w stanie może czerpać z innych usług. Jeśli potrzebujesz takiej kontroli, zazwyczaj przeniósłbym ją do usługi, która wywołuje agregację (w twoim przykładzie WebAppService).

Ponadto może pojawić się przypadek użycia, w którym kilka aplikacji chce jednocześnie wywołać agregację. Jeśli tak się stanie, podczas wykonywania takich połączeń wychodzących, co może zająć dużo czasu, blokujesz agregację dla innych zastosowań. Spowolniłoby to w końcu obsługę agregatów, co moim zdaniem również nie jest pożądane.

Więc chociaż może się wydawać, że twój agregat staje się dość cienki, jeśli przeniesiesz ten fragment sprawdzania poprawności, myślę, że lepiej jest przenieść go do WebAppService.

Sugeruję również przeniesienie publikacji WebAppRegisteredwydarzenia do Twojego agregatu. Agregacja jest tworzonym facetem, więc jeśli proces tworzenia się powiedzie, sensowne jest, aby opublikować tę wiedzę dla świata.

Mam nadzieję, że to pomoże ci @Levidad!