Comment appliquer certains concepts de DDD au code réel? Questions spécifiques à l'intérieur

J'ai étudié DDD et j'ai du mal à trouver un moyen d'appliquer les concepts dans le code réel. J'ai environ 10 ans d'expérience avec N-tier, il est donc très probable que la raison pour laquelle je lutte est que mon modèle mental soit trop couplé à cette conception.

J'ai créé une application Web Asp.NET et je commence avec un domaine simple: une application de surveillance Web. Exigences:

• L'utilisateur doit pouvoir enregistrer une nouvelle application Web à surveiller. L'application Web a un nom convivial et pointe vers une URL;
• L'application Web interrogera périodiquement un statut (en ligne / hors ligne);
• L'application Web interrogera périodiquement sa version actuelle (l'application Web devrait avoir un "/version.html", qui est un fichier déclarant sa version système dans un balisage spécifique).

Mes doutes concernent principalement la répartition des responsabilités, trouver la bonne place pour chaque chose (validation, règle métier, etc.). Ci-dessous, j'ai écrit du code et ajouté des commentaires avec des questions et des considérations.

Veuillez critiquer et conseiller . Merci d'avance!

MODÈLE DE DOMAINE

Modélisé pour encapsuler toutes les règles métier.

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

Et une classe DomainService pour gérer les créations et les suppressions, qui, je crois, ne sont pas la préoccupation de l'agrégat lui-même.

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

COUCHE D'APPLICATION

La classe ci-dessous fournit une interface pour le domaine WebMonitoring vers le monde extérieur (interfaces web, api restes, etc.). C'est juste un shell en ce moment, redirigeant les appels vers les services appropriés, mais il se développera à l'avenir pour orchestrer plus de logique (accompli toujours via des modèles de domaine).

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

Clôturer les affaires

Après avoir rassemblé les réponses ici et dans cette autre question , que j'ai ouverte pour une raison différente mais qui est finalement arrivée au même point que celle-ci, j'ai trouvé cette solution plus propre et meilleure:

Proposition de solution dans Github Gist

Sur de longues lignes de conseils sur votre WebAppagrégat, je suis tout à fait d'accord pour dire que tirer dans le repositoryn'est pas la bonne approche ici. D'après mon expérience, l'agrégat décidera si une action est correcte ou non en fonction de son propre état. Ainsi, pas sur l'état, il pourrait tirer d'autres services. Si vous aviez besoin d'un tel chèque, je le déplacerais généralement vers le service qui appelle l'agrégat (dans votre exemple le WebAppService).

En outre, vous pouvez atterrir sur le cas d'utilisation que plusieurs applications souhaitent appeler simultanément votre agrégat. Si cela se produit, alors que vous effectuez des appels sortants comme celui-ci, ce qui peut prendre du temps, vous bloquez ainsi votre agrégat pour d'autres utilisations. Cela ralentirait éventuellement la gestion des agrégats, ce qui, à mon avis, n'est pas souhaitable non plus.

Donc, même s'il peut sembler que votre agrégat devient assez mince si vous déplacez ce bit de validation, je pense qu'il vaut mieux le déplacer vers le WebAppService.

Je suggère également de déplacer la publication de l' WebAppRegisteredévénement dans votre agrégat. L'agrégat est le type en cours de création, donc si son processus de création réussit, il est logique de le laisser publier ce savoir dans le monde.

J'espère que cela vous aide à @Levidad!