Всегда ли объект должен валидным?

Question

[ddd329]

Привет, ребята.
Допустим, у меня есть в коде объект-сущность Document, у которого имеется свойство RegNumber, т.е. регистрационный номер. Правило такое - регистрационный номер должен быть определенного формата и быть уникальным для каждого документа. Номер может быть сгенерирован автоматически или быть присвоенным вручную. Рассмотрим случай когда пользователь вводит в форму номер документа и View передает этот номер Presenter'у. Если номер оказался неверного формата или не является уникальным, то может ли Presenter присвоить значение свойству RegNumber объекта Document?

Я всегда считал что НЕТ, потому что объект предметной области должен всегда находится в валидном состоянии, т.е. соблюдать все инварианты. Если объект Document имеет какую-то операцию, то после ее выполнения объект должен соблюдать инварианты, а если он до выполнения операции не валиден, то. и после тоже...

Не раз уже видел код, где объекты имеют свойство IsValid, и метод GetBrokenMessages(), который возвращает сообщения о нарушенных бизнес-правилах. Получается они допускают что объект может находится в некорректном состоянии, а как же тогда должны выполняться операции над объектом, когда он некорректен?

И как считываете Вы, может ли объект предметной области на протяжении своего жизненного цикла находится в не валидном состоянии, т.е. нарушая инварианты?

Comments

[Screamie Di]

Привет! А зачем Presenter-у присваивать заведомо неверное значение для Document, если он с ним никуда не уедет? На мой взгляд такие вещи должны валидироваться до присваивания, сеттерами. Что касается полей isValid, то в теории можно представить такие объекты (не обладающие бизнес логикой), которые могут функционировать с невалидными полями какое-то время (например DTO). Думаю, что давать возможность присвоения неверных значений полям объекта, который отвечает за бизнес логику это путь во тьму)

[ddd329]

Согласен, тоже так думаю

Answer 1

[Myroslav Berlad]

Моя позиция по даному вопросу - да, всегда объект должен оставаться валидным если разговор идет о entity или value object.

Рассмотрим случай когда пользователь вводит в форму номер документа и View передает этот номер Presenter'у. Если номер оказался неверного формата или не является уникальным, то может ли Presenter присвоить значение свойству RegNumber объекта Document?

Я б сделал так (не факт что правильно, нужно лучше понимать вашу предметную область, просто исходя из описаного):

На View и с View передавал бы Presentation . Он может быть как раз не валидным. По сути он тупая DTO'шка, всего лиш ресурс. Отдавать напрямую entity не очень хорогая идея. Простой пример - REST. В REST ключевая единица ето ресурс. Ресурс по сути ето проеция или мапинг entity или нескольких entities:

A resource is a conceptual mapping to a set of entities, not the entity that corresponds to the mapping at any particular point in time. Architectural Styles and the Design of Network-bas...

RegNumber - я б делал ValueObject с валидацией внутри (прям в конструкторе ), вот псевдо-код:

class RegNumber
{
    private regNumber;

    private construct(regNumber)
    {
        this.setRegNumber(regNumber);
    }

    private setRegNumber(regNumber)
    {
        this.assertRegNumberIsValid(
            regNumber
        );

        this.regNumber = regNumber;
    }

    public static function create(regNumber)
    {
        return new self(regNumber);
    }

    private function assertRegNumberIsValid(regNumber)
    {
        if (regNumber is bad) {
             throw new InvalidRegNumber()
        }
    }
}

и уже его испольовал в Document. И так, по сути, он всегда будет валидным, так как не валидный объект не сможет создатся

Answer 2

[ddd329]

Да, вопрос как раз об Entity и ValueObject'ы.

Я пишу код на C#, но не суть... Я уже пробовал регистрационный номер выразить в коде через ValueObject, который бы занимался валидацией входной строки, и всегда создавался валидным. По началу казалось мне все проще, я проверял входную строку регулярным выражением, но этого оказалось мало.
Входная строка, которая представляла регистрационный номер состоит из трех частей, первая часть это бизнес-направление, вторая часть вид документа и третья часть это порядковый номер, т.е. надо еще проверять существует ли бизнес-направление и вид документа, да и еще глобальную уникальность самого номера. Я сомневаюсь что этим всем должен заниматься ValueObject т.к. требуется обращение к Repository.

Может сделать так: вынести класс Document в отдельную сборку Domain, выставить у свойства RegNumber модификатор доступа internal, чтобы клиентский код, например Presenter, не смог на прямую устанавливать значения. Ввести доменную службу DocumentService и в нем реализовать логику присвоения регистрационного номера, здесь как раз будет и парсинг строки, и проверка всех частей номера в базе данных обращение к которой будет осуществляться через репозиторий?

Comments

[Myroslav Berlad]

Вполне может быть.

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

а ети правила можно закинуть в Specification

[ddd329]

Myroslav Berlad,

а ети правила можно закинуть в Specification

Если я вас правильно понял, то в итоге у нас "на руках" должен быть ОБЪЕКТ-СПЕЦИФИКАЦИЯ, которая возможно состоит из других спецификаций и более? Что-то наподобие RegNumberIsValidSpecification, который содержит метод IsSatisfiesBy(string regNumber)? Верно или нет?

Если да, то постараюсь объяснить почему на мой взгляд это не очень хорошее решение.

Данный паттерн является не просто техническим программным механизмом, с помощью которого можно комбинировать различные условные выражения, которые позволяют строить очень сложную логику проверок.
СПЕЦИФИКАЦИЯ должна выражать какое-то понятие предметной области, а уже из простых понятий можно строить более сложные путем их объединения. Вот например, у нас есть программа для работы с клиентами, и в нашей предметной области есть такое понятие как "Любимый клиент" и соответствующее бизнес-правило, которое гласит что "любимым клиентам" предоставляется скида 15%. Понятие "любимый клиент" может, например, состоять из таких понятий как "постоянный клиент" и "надежный клиент", плюс еще какие-нибудь дополнительные условия и проверки... Когда в каком-нибудь методе мы будем производить расчет стоимости за оказанные услуги, то проверим является ли клиент "любимым", примерно так :

if (favoriteCustomerSpecification.IsSatisfiesBy(customer))
{
 // здесь вычитаем 15%
}

...

В теории, по данной спецификации, мы можем запросить из CustomerRepository список клиентов, которые являются "любимыми", передав СПЕЦИФИКАЦИЮ как входной параметр методу репозитория.

Теперь вернемся к нашей предметной области, логично ли будет запросить из DocumentRepository список документов которые имеют "валидный" регистрационный номер? В нашей предметной области даже понятия такого не существует... Проверка на корректность входных параметров, это чисто программный механизм, который никак не отражается в моделировании предметной области и соответственно не будет СПЕЦИФИКАЦИЙ, которые моделируют понятия...

Возможно я заблуждаюсь, поправьте пожалуйста, если я где-то не прав..