Объект значения в источнике событий

Я бы сказал, что в тот момент, когда вы переопределили значение Username, и вы каким-то образом не переносите исторические данные, вы, по сути, создали два разных Username значения.

Поскольку у этого слова есть два разных значения, вам нужно как-то явно указать в коде. «Управление версиями» - это один из способов, хотя я бы не стал использовать такое универсальное решение, существуют разные варианты моделирования.

Вы могли бы явно указать, что история «имени пользователя» - это всего лишь история. Так, например, создайте HistoricUsername, который является объектом, источником которого является событие, даже если хотите, объект-значение. И создайте Username, которое всегда является именем пользователя с самыми последними правилами, которое вообще не сохраняется, а создается из HistoricUsername, если это возможно.

Некоторые люди предлагают иногда извлекать «правила» из объекта и применять их позже. Таким образом, сам объект действителен в любое время, и вы можете попросить его проверить себя на соответствие правилам, которые могут измениться. Я не особо предпочитаю такие решения, но это вариант, и Username все равно будет объектом-значением.

Так что проблема не в том, что объекты-значения не подходят для источников событий, а в том, что моделирование должно быть более точным.

Есть ли вообще место для ценностных объектов в доменах с источником событий?

да.

Есть ли более простой способ избежать таких проблем?

«Не делай этого».

Проблема, которую вы описываете, на самом деле связана с обменом сообщениями - если мы внесем обратно несовместимые изменения в наши сообщения, все сломается.

(Точнее, у вас есть сообщение «Имя пользователя», и вы пытаетесь повторно использовать это сообщение с новым набором ограничений, которые отклоняют некоторые ранее допустимые варианты использования сообщения).

Ответ заключается в том, что вы не вносите обратно несовместимых изменений - вместо этого вводите новые имена, которые соответствуют новым требованиям, и исключите старые.

Другими словами, добавление поддержки новых сообщений и удаление поддержки старых сообщений стали двумя отдельно управляемыми вариантами.

В книге Грега Янга Версионирование в системе с обработкой событий этой идее посвящено несколько глав. Кроме того, Рич Хики затрагивает эти важные идеи в большинстве своих выступлений - я бы предложил начать с Спецификация.

«Объект значения», означающий, что тип, который текущая реализация модели предметной области использует для перемещения информации, представляет собой отдельную заботу от сообщений. Структуры данных, которые мы используем в памяти, не обязательно должны быть связаны с нашими форматами сериализации.

Представление информации в сети отличается от представления информации в памяти, а это, в свою очередь, отличается от абстракций, которые управляют информацией в памяти.

Сложность состоит в том, что в начале проекта у вас есть наименьшее количество информации о том, когда различные представления будут расходиться.

Мы решили это немного по-другому. Отделив общедоступный API наших объектов значений от внутреннего (только для домена) API, мы можем развивать один, не затрагивая другой.

Например:

public class Username
{
    private readonly string value;

    // Domain-only (internal) constructor.
    // Does not enforce constriants and can only be called within the domain.
    internal Username(string value)
    {
        this.value = value;
    }

    // Public factory method.
    // Enforces business constraints. Used by consumers of the domain (application layer etc.)
    // to create new instances of the value object.
    public static Username Create(string value)
    {
        // Business constraints. These will evolve and grow over time.
        if (value == null)
        {
            // throw exception etc.
        }

        if (value.Length < 2)
        {
            // throw exception etc.
        }

        return new Username(value);
    }
}

Потребители домена должны использовать статический метод Create для создания нового экземпляра объекта значения. Этот фабричный метод содержит все наши бизнес-ограничения и предотвращает создание экземпляра в недопустимом состоянии.

Внутри домена классы имеют доступ к внутреннему конструктору (без ограничений). Поскольку это не налагает никаких бизнес-ограничений, экземпляр объекта значения всегда может быть создан таким образом (независимо от его значения). Используя этот конструктор при воспроизведении событий, мы можем гарантировать, что исторические данные всегда будут успешными.

Преимущества такой конструкции:

• Один класс используется для представления концепции предметной области (нет необходимости в нескольких классах, управлении версиями и т. Д.).
• Бизнес-правила могут развиваться со временем.
• Исторические данные всегда работают. Username год назад по-прежнему остается именем пользователя, даже если наши правила изменились.

Хотя я уже ответил, я считаю, что это интересная ситуация.

Я согласен с другими в том, что данные о событиях должны быть основаны на записях и, следовательно, не более чем контейнер данных, который можно использовать для восстановления агрегата.

При этом, когда меняются правила, меняется и домен. Основная часть проектирования, ориентированного на предметную область, заключается в том, чтобы охватить как можно большую часть предметной области (правил / структуры). Если это так, следует ли не сохранять изменения в правилах?

Например, если у нас есть Username объект значения и он начинается с правил от 2 до 16 символов, то он кодируется следующим образом:

public class Username
{
    public string Value { get; }

    public Username(string value)
    {
        if (value.Length < 2 || value.Length > 16)
        {
            throw new DomainException("Username must be between 2 and 16 characters");
        }

        Value = value;
    }
}

Теперь мы переходим к 1 марта 2018 года, и правила меняются. Мы можем сохранить правило:

public class Username
{
    public string Value { get; }

    public Username(string value, DateTime registrationDate)
    {
        if (registrationDate < new Date(2018, 3, 1) &&
            (value.Length < 2 || value.Length > 16))
        {
            throw new DomainException("Username must be between 2 and 16 characters");
        }

        if (registrationDate >= new Date(2018, 3, 1) &&
            (value.Length < 5 || value.Length > 16))
        {
            throw new DomainException("Username must be between 5 and 16 characters");
        }

        Value = value;
    }
}

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

Просто мысль.