mayton2019, видимо поэтому о нем никакой инфы и нет. спасибо большое за развернутый ответ, тогда буду читать статьи на Хабре прокашлянных компаний по типу яндекса (вроде натыкался даже на их статью про идемпотентность в апи навигатора)
да, тут я наверное не очень точно выразил вопрос...
мне бы хотелось больше понять про проектирование по, а это соответственно разного рода модели данных - EAV, например. Честно, кроме как в википедии ничего больше про эту модель не нашел. Может книжки умные есть на такой случай?
Про event sourcing тоже соглашусь, ибо я сам не с первого раза догнал в чем его идея... но тут скорее вопрос про историчность (?) данных и в таком духе best practices в общем.
Вот про кеши (осбенно нормальные реализации, а не helloy worldы с декораторами на репозиториях, которые даже в транзакцию не могут) хотелось бы почитать подробнее. Может, подскажете что вообще следует делать? Мб тупо залазить на гитхаб и читать? Или есть литература соответствующая... memcached, microsoft memory... так, поверхностно только понимаю.
А книжка по микросервисам есть на русском переводе? Боюсь, всех деталей на английском не пойму. Все-таки не про код книжка.
Somov62, отчасти да - у каждого микросервиса свое представление одной и той же сущности, если такая есть - это называется bounded context, например в мс пользователей - фио, телефон, адрес ну и т.п
а в доменном микросервисе - достаточно просто account_id или же другие параметры - настройки сортировок, настройки аккаунта и так далее
Сергей, clean architecture подразумевает собой отделение доступа данных от их отображения. репозитории как и service являются просто слоем.
микросервис в свою очередь является частью доменной логики, не инфраструктурной! если б микросервис работал с емейлами или, например,с аутентификацией, то это SOA (service-oriented architecture)
тогда будет проще использовать готовые шаблоны. Изначально передавал саму сущность, по которой сопоставлялся запрос, но в итоге отказался из-за отсутствия гибкости и сложности
Все вхождения условий - это ветвление кода. Любой ЯП требует, чтобы все ветви возвращали значение. У вас же функция завершится только тогда, когда вызовется for. Вопрос - а если не вызовется? Поэтому шарп и ругается.
Надо иметь экземпляр события, определяемое через event
Затем, в методе, где изначально создается переменная (ну... т.е под капотом), вызывается событие при каждом изменении переменной. Делаются проверки имеются ли привязанные обработчики события и уже вызываются
если из статичности данных и нормальных форм говорить, то лучше паспортные оставить у самого спортсмена. Поскольку они не поменяются. А вот возраст и т.д. - уже в отдельной таблице, т.к меняются.
Для российского вряд ли получится, для этого есть валидация. Есть data type - phone_number для поля.
Для биографии 255 символов будет маловато
creating, в основном записывается как created_at
Для паспортных данных лучше создать таблицу по типу "участники" id спортсмена, паспортные, заявочные на конкурс данные, возраст.
Остальные поля оставить к таблице спортсменов.