Path somewhere from Anemic models

[Adelf]

Есть у меня медицинский проект и там у сущности User есть аттрибут license. Т.е. какая у него медицинская лицензия. Доктор он там(MD) или медсестра.
Храню это как строка, но эта строка может иметь только несколько определенных значений.
Нормально ли в здоровой DDD модели иметь статичную функцию User::getAvailableLicenses() - который возвратит список возможных лицензий?
А то я то все в своих анемиках ковыряюсь. И уже в паре сервисов понадобилось... $userRegistrator->getAvailableLicenses() - при самостоятельной регистрации юзера, $userInviter->getAvailableLicenses() - при приглашении юзера администратором.
И это меня начало напрягать. Потихоньку постигаю дзен и прихожу к нормальным моделям. Вот и спрашиваю у опытных.

 

[fixxxer]

enum

 

[Вурдалак]

Сам по себе license в таком случае не должен быть просто строкой, нужен VO, который будет проверять принадлежность к фиксированному множеству. Ну, enum, короче, да.

 

[Adelf]

ну enum в базе - это понятно.
VO - тоже понятно. И там уже можно getPossibleLicenses() чтобы было чем заполнять select?

 

[Вурдалак]

Я бы скорее даже просто продублировал этот список в presentation.

 

[Adelf]

Я вот поэтому и спрашиваю. Я из Presentation слишком глубоко в модель лезу. И от этого неловко.
Но дублировать тоже не хочу. Single source of truth и все такое.

 

[fixxxer]

enum в базе

а я не про базу

 

[Вурдалак]

Да обычно нафиг тут не нужно добиваться SSoT, на самом деле

На практике будут примеры, когда это по объективным невозможно, либо сложно.

К примеру, захотят дизайнеры сделать select в виде картинок, тебе всё равно придётся на каждый вариант каким-то образом прописывать путь к картинке. Не делать же это в самой модели, это будет где-то в шаблоне, например. В итоге шаблон всё равно будет знать реальный список значений.

Похожая ситуация с клиентами, которые не могут обновиться параллельно с моделью: iOS, Android. Там либо тянуть с сервера, либо-таки хардкодить.

При этом иногда проверки в модели и в клиенте разные намеренно (когда в клиенте более жесткие проверки).

Вот ещё на тему:
http://gorodinski.com/blog/2012/05/19/validation-in-domain-driven-design-ddd/
http://verraes.net/2015/02/form-command-model-validation/

 

[HORO]

А какие проблемы могут возникнуть если "иметь статичную функцию User::getAvailableLicenses()" ?

 

[Adelf]

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

Ах да, я же обещал тебя дедовщиной обеспечить. Короче, тебе, салага, это не понять. ;-)

 

[HORO]

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

 

[Sufir]

enum

Оптимально решает задачу. Сам с этим бился недавно, тоже пробовал и копипасту и из домена тащить, с Enum отлично получается.

 

[Adelf]

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

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

 

[HORO]

Иными словами, проблемы могут возникнуть если в будующем кто-то решит проект разделить...
Забавно, я сегодня тоже думал о будущей проблеме 2038 года, когда решал юзать timestamp или datetime

 

[Вурдалак]

Также у нас система может быть построена на микросервисах каких-нибудь и из веб-части тоже User будет недоступен

Эта проблема чем-то напоминает https://en.wikipedia.org/wiki/CAP_theorem Добиться согласованности модели и интерфейсов без потери других качеств невозможно.

 

[Adelf]

Да. похоже.