Замена примитива объектом в доменной модели

Типы данных можно разделить на примитивные и пользовательские. Примитивы хранят некоторое скалярное значение, например число или символ (int, bool, char, decimal и др). Пользовательскими типами являются те, которые создает непосредственно программист, с целью сгруппировать несколько примитивов в одну логическую единицу и добавить к ним логику. Пользовательские типы описывают при помощи классов или структур, а конкретными примерами являются типы Person, Address, Order, Product и так далее до бесконечности.

Описание проблемы
Решение: замена примитива объектом
Преимущества подхода
Недостатки подхода
Почитать дальше

Описание проблемы

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

public class User
{
    public long Id { get; set; }
    public string Email { get; set; }
    public int Discount { get; set; }
}

Для свойств Email и Discount прогнозируемо были выбраны типы string и int соответственно, которые справляются со своей основной задачей — хранением значения, но их использование не дает никакой гарантии, что значения всегда будут валидными. Диапазон значений, которые могут хранить string и int превышают диапазон значений удовлетворяющих требованиям логики разрабатываемого приложения. Простыми словами не каждая строка является email’ом и не каждое число — дисконт. Email должен выполнять целый ряд условий, таких как наличие символа ‘@’ и других, а значение Discount не может быть меньше одного и больше ста.

При возникновении подобных ограничений разработчик вынужден думать о валидации значений. В самом лучшем случае валидировать придется один раз при передаче данных из контролера или сервиса в доменную модель, в худшем — много раз: при создании объекта User, при обновлении значений Email или Discount, при передаче Discount в доменный сервис Calculator для выполнения некоторых расчетов и так далее. В результате можем получить дублирующуюся логику валидации, размазанную тонким слоем по всему приложению, которая будет выглядеть где-то так:

public class User
{
    public int Discount { get; set; }
    public void ChangeDiscount(int discount)
    {
        if (discount < 1 && discount > 100)
            throw new BusinessLogicException("Invalid discount");
        Discount = discount;
    }
}

public class Calculator
{
    public int Calculate(int discount)
    {
        if (discount < 1 && discount > 100)
            throw new BusinessLogicException("Invalid discount");
        //calculate ...
    }
}

public class EmailService
{
    public void SendEmail(string email)
    {
        if (!Regex.IsMatch(email, @"^\S+@\S+$"))
            throw new BusinessLogicException("Invalid e-mail");
        //send email ...
    }
}

Решение: замена примитива объектом

Для решения проблем можно воспользоваться подходом, который не допустит присутствие невалидных значений в пределах бизнес-логики вообще, в результате чего отпадет необходимость думать том, провалидированы ли значения везде где требуется, а правила валидации будут собраны в единственном месте. Для достижения цели необходимо заменить примитив классом, который должен заключать в себе:

публичное свойство для хранения примитива
приватный конструктор
фабричный метод для создания объекта, с предварительной валидацией

Создадим классы User и Discount, следуя правилам выше:

public class Email
{
    private Email(string email) => Value = email;
    public string Value { get; }
    public static Email Create(string email)
    {
        if (!Regex.IsMatch(email, @"^\S+@\S+$"))
            throw new BusinessLogicException("Invalid e-mail");
        return new Email(email);
    }
}

public class Discount
{
    private Discount(int discount) => Value = discount;
    public int Value { get; }
    public static Discount Create(int discount)
    {
         if (discount < 1 && discount > 100)
            throw new BusinessLogicException("Invalid discount");
        return new Discount(discount);
    }
}

А сам класс User изменится следующим образом:

public class User
{
    public long Id { get; set; }
    public Email Email { get; set; }
    public Discount Discount { get; set; }
}

Преимущества подхода

Использование классов Email и Discount в доменной модели (в классах User, Calculator, EmailService), которые невозможно создать с невалидными значениями, дает несколько преимуществ:

Логика валидации собрана в единственном месте, что максимально упрощает внесение в нее изменений.
Нет никакой необходимости думать о валидации Email или Discount перед их использованием, так как эти объекты гарантировано содержат валидные значения.
Объекты являются неизменяемыми, что защищает приложение побочных эффектов, связанных с Email и Discount.
Когда программист натыкается в коде на объекты Email или Discount, у него уйдет одна секунда на нахождение соответствующей логики валидации.

Недостатки подхода

Свойство-объект с единственным примитивом внутри сложнее мапить на колонку в таблице базы данных при работе с ORM, чем свойство-примитив. Тем не менее Entity Framework Core позволяет достаточно легко это сделать при помощи механизма Value Conversions.
Неизменяемость создаваемых объектов в отдельных случаях может привести к проблемам с производительностью, при попытках их частых «изменений».