Может ли модель чтения с управлением доменом иметь базовую c логи c? - PullRequest
0 голосов
/ 09 апреля 2020

У меня вопрос по поводу read models. Я использую модели чтения, когда получаю данные из базы данных и эквивалентные модели сущностей / агрегатов для использования в репозиториях. Мой вопрос: может ли read model класс иметь constructor, который проверял бы properties? Например, мог бы я иметь такой read model class. С другой стороны, у меня уже есть такие проверки в модели эквивалентной области EmployeeModel, поэтому я не уверен, что это будет немного дублирования. Дополнительный вопрос будет, если в моем EmployeeModel (домен) нет nullable EmploymentDate, могу ли я пометить его как nullablein, если модель чтения означает, что модель чтения может быть другой, что эквивалентно domain model?

class EmployeeReadModel
{
     public DateTime? EmploymentDate { get; set; }
}

Могу ли я добавить конструктор и проверить на такую ​​модель чтения?

class EmployeeReadModel
{
     public DateTime? EmploymentDate { get; set; }

     EmployeeReadModel(DateTime? employeeDate)
     {
           EmploymentDate = employeeDate?? throw new Exception();
     }
}

Ответы [ 2 ]

1 голос
/ 10 апреля 2020

Может ли модель чтения, управляемая доменом, иметь базовую c logi c?

Обычно у вас не будет логики домена c, в смысле " конечные автоматы "в модели чтения.

Однако у вас есть ограничения, которые могут вам понадобиться, которые не соответствуют имеющимся у вас данным.

Например, предположим, что я ' m отправил запрос с ID:12345, и я должен ответить сообщением, используя схему Foo, которая включает член Bar, который ограничен целочисленными значениями 0-9. Мы смотрим в книгу рекордов, используя ID:12345, и обнаруживаем, что модель предметной области решила, что «это одиннадцать».

Таким образом, доступные данные не соответствуют необходимым предварительным условиям. И что теперь?

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

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

Одна из приятных вещей в cra sh при конфликте заключается в том, что он сильно тянет шнур Андона - все останавливается. Бонус - это действительно легко обнаружить. Недостатком, конечно, является то, что вы теряете доход, пока не получите развернутое исправление.

Недостатком является то, что многие вещи могут попасть в радиус взрыва кратера sh. И, в частности, если ваши инструменты мониторинга и восстановления не могут работать из-за сбоя в конфликте, это будет очень трудно исправить.

Другими словами, мы хотим быть очень точными - это не ответственность модели чтения за обнаружение правильного поведения модели записи или операторов-людей; Задача модели чтения - определить, может ли модель чтения соответствовать собственным требованиям с предоставленными данными.

1 голос
/ 09 апреля 2020

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

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

Учитывая, что модель чтения - это скорее объект передачи данных, есть вероятность, что как только она выйдет из вашей системы, получающая система будет использовать ее явно как данные. Например, даже веб-интерфейс будет анализировать json представление данных для их использования.

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

...