Привет! Спасибо за статью! Рассматривали ли вы вариант делать микросервисы на одной базе аля своём фреймворке , который под капотом умеет слать все общие между микросервисами метрики? Если да, то почему такой вариант не подошёл? Тогда в графане достаточно было просто сделать один раз общий дашборд на котором сделать переключатель по микросервисам. У нас так сделано и не надо ничего изобретать ? все микросервисы конечно при таком подходе должны использовать общие методы логирования, воркеров, консьюмеров, контроллеры веб сервера и тд
У меня даже с премиумом не работает режим «картинка в картинке» в приложениях ютуб на айфоне и айпаде. Чтобы воспользоваться этой функцией нужно обязательно открывать ютуб через браузер.
> И да, я считаю, что в енамах значение по умолчанию всегда должно быть неопределённым.
Неопределенным или неизвестным? Это разные вещи. Оба варианта могут быть присущи полю типа enum.
Ребята вы молодцы. Одна маленькая просьба. Учитывайте что есть те, кто слушает подкаст на скорости x1.5. У вас речь бывает не равномерная по скорости. Что-то говорите быстро, что-то медленно. Например, когда читаете «могли бы обсудить, не обсудили», делаете это очень быстро и на x1.5 некоторые слова «проглатываются». Старайтесь прослушивать подкаст перед публикацией на повышенных скоростях. Спасибо!
> А просто не использовать поле не по назначению.
Если вы считаете, что поле sex может содержать значения только «мужской» и «женский», а всё остальное это «не по назначению», то вы ошибаетесь. Если взять стандарт ISO 5218 то поле sex может иметь не 2, а 4 значения.
Ну допустим. А если нас появится пол «унисекс», когда персонаж может иметь мужской и женский пол, например, для того чтобы в sims 4 можно было одевать разную одежду. И это может быть «другое» как у автора статьи на скриншоте. И тогда мы опять приходим к тем проблемам, которые обозначил автор статьи.
Устраивает. Но optional мы сможем применить только один раз по отношению к полю. А значений у нас может быть много: не определен, не известен, не применим и т.д. И это разные по смыслу и назначению вещи.
Возможно вы правы. Не претендую на истину. Но тогда наш объект приобретает две роли, валидация и хранение значения.
И есть еще вопрос, не связанный напрямую с темой. Судя по пространству имен и PSR-4 вы храните Domain object и Value object в одной директории. Насколько это оправдано?
Это не пол, но значение вполне может храниться в поле sex.
> Если есть такое поле, значит есть и другие поля, которые «не определены»
Абсолютно не значит. Других полей может не быть, которые не определены. Если у вашего объекта всего два поля «имя» и «пол». Имя известно, пол не определен. Допустим вы добавите отдельное поле, например, булево отражающее определен пол или не определен, тогда вы можете столкнуться с ситуацией когда ваш объект будет иметь пол «мужской» и тип «пол не определен».
Предположим, что функция hasSex отвечает у нас за применимо или не применимо понятие «пол». А сам пол мы отобразим в базе как нулевое поле. Через какое то время у нас появляется новое понятие, пол «не известен». Итого у нас есть «пол не применим», «пол не определен», «пол не известен», «другой». Нулевое значение у нас уже занято. Функция hasSex задействована. Каким образом вы будете решать появление нового значения «не известен»? Разумеется разделять эти понятия не имеет смысла, так как у нас объект не может иметь одновременно и «мужской пол» и статус «не определен» или «женский пол» и статус «пол не применим».
Я просто хочу вам сказать, что вы можете ошибаться, когда думаете что знаете точное количество значений, на примере поля sex. В процессе разработки, например компьютерной игры, могут появляться новые значения, которые на этапе планирования не заложили. А соответственно тогда и начнутся те самые проблемы, которые описал автор в своей статье.
Мне кажется у вас нарушен принцип единственной ответственности, когда вы в value object начинаете проверять валидность данных, через функцию assert. Проверку на валидность данных лучше выносить в отдельный слой.
> Если пол не применим к объекту, следует отделить объекты, к которым пол применим, для других enum просто не потребуется.
Интересно каким образом вы отделите объекты к которым пол не применим, если они хранятся в одной таблице и имеют одинаковые свойства с теми у которых пол применим? Создадите отдельную таблицу или класс под них?
Привет! Спасибо за статью! Рассматривали ли вы вариант делать микросервисы на одной базе аля своём фреймворке , который под капотом умеет слать все общие между микросервисами метрики? Если да, то почему такой вариант не подошёл? Тогда в графане достаточно было просто сделать один раз общий дашборд на котором сделать переключатель по микросервисам. У нас так сделано и не надо ничего изобретать ? все микросервисы конечно при таком подходе должны использовать общие методы логирования, воркеров, консьюмеров, контроллеры веб сервера и тд
У меня даже с премиумом не работает режим «картинка в картинке» в приложениях ютуб на айфоне и айпаде. Чтобы воспользоваться этой функцией нужно обязательно открывать ютуб через браузер.
Неопределенным или неизвестным? Это разные вещи. Оба варианта могут быть присущи полю типа enum.
Не нашел инфу о поддержке DOH в браузере TOR… можете что то прояснить?
Если вы считаете, что поле sex может содержать значения только «мужской» и «женский», а всё остальное это «не по назначению», то вы ошибаетесь. Если взять стандарт ISO 5218 то поле sex может иметь не 2, а 4 значения.
В таком случае исключения не будет, если вы это хотели сказать своим комментарием.
Я к тому что DO и VO это же разные по смыслу вещи, разве нет?
Вы можете называть это как угодно. Сути не меняет.
И есть еще вопрос, не связанный напрямую с темой. Судя по пространству имен и PSR-4 вы храните Domain object и Value object в одной директории. Насколько это оправдано?
Это не пол, но значение вполне может храниться в поле sex.
> Если есть такое поле, значит есть и другие поля, которые «не определены»
Абсолютно не значит. Других полей может не быть, которые не определены. Если у вашего объекта всего два поля «имя» и «пол». Имя известно, пол не определен. Допустим вы добавите отдельное поле, например, булево отражающее определен пол или не определен, тогда вы можете столкнуться с ситуацией когда ваш объект будет иметь пол «мужской» и тип «пол не определен».
Я просто хочу вам сказать, что вы можете ошибаться, когда думаете что знаете точное количество значений, на примере поля sex. В процессе разработки, например компьютерной игры, могут появляться новые значения, которые на этапе планирования не заложили. А соответственно тогда и начнутся те самые проблемы, которые описал автор в своей статье.
Интересно каким образом вы отделите объекты к которым пол не применим, если они хранятся в одной таблице и имеют одинаковые свойства с теми у которых пол применим? Создадите отдельную таблицу или класс под них?