Как применить некоторые концепции DDD к реальному коду? Конкретные вопросы внутри

9

Я изучал DDD, и в настоящее время я пытаюсь найти способ применить концепции в реальном коде. У меня около 10 лет опыта работы с N-ярусом, поэтому очень вероятно, что я борюсь за то, что моя ментальная модель слишком связана с этим дизайном.

Я создал веб-приложение Asp.NET и начинаю с простого домена: приложения веб-мониторинга. Требования:

  • Пользователь должен иметь возможность зарегистрировать новое веб-приложение для мониторинга. Веб-приложение имеет понятное имя и указывает на URL;
  • Веб-приложение будет периодически запрашивать статус (онлайн / офлайн);
  • Веб-приложение будет периодически запрашивать его текущую версию (ожидается, что веб-приложение будет иметь «/version.html», то есть файл, в котором указана его системная версия в определенной разметке).

Мои сомнения касаются в основном разделения обязанностей, поиска подходящего места для каждой вещи (проверка, бизнес-правила и т. Д.). Ниже я написал некоторый код и добавил комментарии с вопросами и соображениями.

Пожалуйста, критикуйте и советуйте . Заранее спасибо!


ДОМЕННАЯ МОДЕЛЬ

По модели инкапсулировать все бизнес-правила.

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

И класс DomainService для обработки «Создает и удаляет», что, я считаю, не является проблемой самого Агрегата.

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

СЛОЙ ПРИМЕНЕНИЯ

Класс ниже предоставляет интерфейс для домена WebMonitoring с внешним миром (веб-интерфейсы, остальные API и т. Д.). На данный момент это всего лишь оболочка, перенаправляющая вызовы на соответствующие сервисы, но в будущем она будет расти, чтобы управлять большей логикой (что достигается всегда с помощью моделей предметной области).

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

Закрытие вопросов

После сбора ответов здесь и в этом другом вопросе , который я открыл по другой причине, но в конечном итоге добрался до той же точки, что и этот, я пришел к более чистому и лучшему решению:

Предложение решения в Github Gist

Levidad
источник
Я много читал, но я не нашел таких практических примеров, кроме тех, которые применяют CQRS и другие ортогональные шаблоны и практики, но я сейчас ищу эту простую вещь.
Левидад
1
Этот вопрос может лучше подойти для codereview.stackexchange.com
VoiceOfUnreason
2
Вы мне нравитесь, потому что много времени проводите с n-уровневыми приложениями. Я знаю о DDD только из книг, форумов и т. Д., Поэтому буду публиковать только комментарии. Существует два типа проверки: проверка ввода и проверка бизнес-правил. Проверка входных данных выполняется на уровне приложений, а проверка доменов - на уровне доменов. WebApp выглядит больше как сущность, а не как совокупность, а WebAppService больше похож на службу приложений, чем на DomainService. Также ваша совокупность ссылается на Контейнер, который является инфраструктурной проблемой. Это также выглядит как сервисный локатор.
Адриан Ифтоде
1
Да, потому что это не моделирует отношения. Агрегаты моделируют отношения между объектами домена. WebApp имеет только необработанные данные и некоторое поведение и может иметь дело, например, со следующим инвариантом: не нормально обновлять версии как сумасшедшие, то есть переходить на версию 3, когда текущая версия 1.
Adrian Iftode
1
Пока у ValueObject есть метод, который реализует равенство между экземплярами, я думаю, все в порядке. В вашем сценарии вы можете создать объект значения версии. Проверьте семантическое управление версиями, вы получите множество идей о том, как вы можете смоделировать этот объект значения, включая инварианты и поведение. WebApp не должен общаться с репозиторием, на самом деле я считаю безопасным не иметь ссылки из вашего проекта, которая содержит материал домена, на что-либо еще, связанное с инфраструктурой (репозитории, единица работы), прямо или косвенно (через интерфейсы).
Адриан Ифтоде

Ответы:

1

Долгие советы по вашей WebAppсовокупности, я полностью согласен с тем, что использование repositoryэтого подхода не является правильным подходом. По моему опыту, Агрегат будет принимать «решение», будет ли действие приемлемым или нет, основываясь на своем собственном состоянии. Таким образом, не в состоянии это может вытянуть из других услуг. Если вам понадобится такая проверка, я, как правило, перенесу ее в службу, которая вызывает агрегат (в вашем примере - WebAppService).

Кроме того, вы можете использовать тот вариант использования, в котором несколько приложений хотят одновременно вызывать ваш агрегат. Если это произойдет, пока вы делаете подобные исходящие вызовы, которые могут занять много времени, вы тем самым блокируете свой агрегат для других видов использования. Это в конечном итоге замедлит обработку агрегатов, что, на мой взгляд, нежелательно.

Таким образом, хотя может показаться, что ваша совокупность становится довольно тонкой, если вы перенесете эту часть проверки, я думаю, что лучше перенести ее в WebAppService.

Я бы также предложил перенести публикацию этого WebAppRegisteredсобытия в ваш агрегат. Совокупность - это созданный парень, поэтому, если процесс его создания успешен, имеет смысл разрешить ему опубликовать это знание в мире.

Надеюсь, это поможет вам @Levidad!

Стивен
источник
Привет Стивен, спасибо за ваш вклад. Я открыл еще один вопрос, который в конечном итоге добрался до той же самой точки этого вопроса, и, наконец, я придумал попытку более чистого решения этой проблемы. Не могли бы вы взглянуть и поделиться своими мыслями? Я думаю, что это идет в направлении ваших предложений выше.
Левидад
Конечно, Левидад, я посмотрю!
Стивен
1
Я только что проверил оба ответа: «Голос неразумности» и «Эрик Эйдт». И то и другое соответствует тому, что я бы прокомментировал по поводу вопроса, который у вас есть, поэтому я не могу добавить ценность. И, чтобы ответить на ваш вопрос: то, как вы WebAppнастраиваете AR в «Чистом решении», которым вы делитесь, действительно соответствует тому, что я считаю хорошим подходом для Агрегата. Надеюсь, это поможет тебе, Левидад!
Стивен