Всем привет. Я только начинаю погружаться в DDD и мне

Question

Всем привет. Я только начинаю погружаться в DDD и мне

интересно узнать ваше мнение. Насколько корректно использовать методы непосредственно в сущностях? К примеру могу ли я использовать методы в которых буду проводить валидацию свойств сущности и далее присваивать значение этим же свойствам? Или так делать не стоит?

В интернете нашёл кучу споров на эту тему и у многих очень разные точки зрения

#backend #dot #programming #russian

0

25.07.2023

8 ответов

16 просмотров

Ivan_Karaush Автор вопроса

Сергей L f
Зависит от валидации. Обычно имеем 2-3 отдельные ...

Ну у меня простая валидация email, name, phoneNumber, что-то типо этого 🤷‍♂ Тут я использую Guard Clauses и обычный regex А некоторые видео валидацию прям через аксессоры делают, кто-то в методах, кто-то выносит в другие классы и на фоне этого всего запутался малость)

0

25.07.2023

Дмитрий Алексеев

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

0

25.07.2023

Ivan_Karaush Автор вопроса

Дмитрий Алексеев
Кроме споров ничего и не найдете, ДДД это не про в...

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

0

25.07.2023

Дмитрий Алексеев

Ivan_Karaush
нее я работаю в команде) и дали задание описать су...

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

0

25.07.2023

Дмитрий Алексеев

Ivan_Karaush
нее я работаю в команде) и дали задание описать су...

И немного отсебятины добавлю из опыта, валидацию на корректность и заполненность значений редко определяют в доменный язык, ибо предполагается что мы проверяем данные на входе, а дальше работаем с чистыми данными в БЛ, а вот валидацию вида хватает ли бабла, или есть ли на складе товар и прочее такое однозначно определяется в общий язык, так как такие проверки являются основой общения команды и специалистов заказчика, а говорить со специалистами о том что например емайл должен быть заполнен и соответствовать шаблону обычно нет нужды )

0

25.07.2023

Ivan_Karaush Автор вопроса

Дмитрий Алексеев
И немного отсебятины добавлю из опыта, валидацию н...

нее у меня валидация совсем простенького вида) всего лишь проверка email, name, phoneNumber и проверка аватарки на .png/.jpg

0

25.07.2023

Дмитрий Алексеев

Ivan_Karaush
нее у меня валидация совсем простенького вида) все...

Ну как я и сказал выше ваша команда определяет что и как, нет тут однозначно прописанных правил ) Все зависит от команды что она считает важным для включения в общий язык а что нет. ну и от проекта в целом. Отсюда и такое разнообразие мнений и реализаций...

0

25.07.2023

Сергей L f · Accepted Answer

Зависит от валидации. Обычно имеем 2-3 отдельные почти одинаковые модели. Например для EF и для представления скажем срать в api. Для этого тебе нужно будет дублировать логику валидации. А это плохо, так как если логика изменится, нужно учесть все места где она дублируется. Плюс зона ответственности бывает. Плюс логика бывает динамической, скажем валидации ip адреса нового и старого формата разнится кординально. А если будет ещё один, плюс черный и белый список. То вынося это туда, где оно не нужно, можно поесть говна

170 похожих чатов

Всем привет. Я только начинаю погружаться в DDD и мне

8 ответов

Похожие вопросы