Как более правильно сохранять в одном действии связанные сущности?

В рамках архитектуры Laravel - как это правильно делать?

Нету "архитектуры Laravel". Есть архитектура вашего приложения. Laravel не диктует архитектуру вашего приложения. Если фреймворк диктует архитектуру приложения - это не должен быть фреймворк общего назначения как минимум.

1. Как разграничить в одной форме данные между разными моделями? Через input-массивы вида fileld[model]?

На фронтенде нету ваших "моделей". Есть поля формы и ничего больше, какие модели нужно править, и к какой модели какие поля относятся - забота вашего бэкенда. Формы и модели не должны зависеть друг от друга никак.
Пришли данные - работайте с ними как вам надо. Мапьте на разные DTO если нужно.

Как обрабатываются в таком случае ошибки?

Как обычно, а какие проблемы?
Провалидировали данные => вернули ошибку если что-то не так.

Будут ли нормально отрабатывать Request-классы с валидацией и вывод ошибок?

А почему им вдруг не работать? Они же никак не связаны с вашими моделями.

3. Как должен примерно выглядеть код сохранения множественных/связанных моделей?

Ну, если у вас AR то

$model1->save(); 
$model2->save();

связанных

Погуглил за вас, ушло 20 секунд(в любом случае быстрее чем ждать помощи на Тостере):
"If you would like to save your model and all of its associated relationships, you may use the push method: ..." (c) документация

Правильно ли сделана связь?

Связь по ID - нормально.

Проектирование доменной модели до того как известно её поведение - позже
могут обнаружиться ошибки(хотя они всегда будут, потому итеративная разработка, постепенный рефакторинг и прочие прелести нужны). Тут вопрос в том, будет ли логика в классе, например, Discipline, или инфа по сути справочная, т.к. на текущий момент информация там выглядит не очень связно.

Правильно ли я настроил связи промежуточной таблицы?

Ну, во первых - почему константы торчат наружу(public)?

public const STATUS_OPEN = 'open';
public const STATUS_CLOSED = 'closed';

А во вторых, что такое Event Discipline из вашего кода ну никак не ясно, как не ясно, например, почему эту инфу не поместить в агрегат Discipline

Как правильно реализовать создание дочерних экземпляров класса?

Alex Wells, Хм. Действительно, что-то я совсем не подумал. supports() тут не замена дженерикам, чуть разные области применения.

Дженерики могут лишь помочь с типизацией когда различаются типы аргументов в реализациях интерфейса (Event handler`ы там, RequestHandler`ы для разных объектов Request, нормалайзеры для объектов etc.).

Как правильно реализовать создание дочерних экземпляров класса?

RMate , Кстати, приведённый вариант с дженериками лучше костыля с supports(). Если вопрос безотносительно конкретного ЯП, по возможности лучше такой вариант рассмотреть.

Как правильно реализовать создание дочерних экземпляров класса?

Антон Р., Да. Над названием конечно можно ещё подумать.

Как оптимизировать near by поиск?

R-tree индексы или Геохэши. В популярных базах есть.
Гуглите - "geospatial indexes *название_вашей_субд*"

Модели в паттернах MVC/MVP?

Антон Р.,

Не помню как называется принцип но в общем смысл - задачей должен заниматься объект обладающий наиболее полной информацией для этого действия.

Это Information Expert из GRASP, но у вашего сервиса в принципе нету собственного состояния, потому об "обладает более полной информацией" речи быть не может.

Как лучше организовать общение с микросервисом?

vetsmen, Приложение пишет в очередь, отдельные процессы-демоны разбирают очередь - это прям стандартнейшая схема

Как лучше организовать общение с микросервисом?

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

Как лучше организовать общение с микросервисом?

Ни что не истина все дозволено, и очень сильно зависит от задач. Я не думаю, что смогу рассказать это точно так же как Илья Климов *ссылка на лекцию по микросервисам*

Автор курса даже не удосужился разобраться чем микросервисы от монолита отличаются, не нужно такую чушь рекламировать.

Как лучше организовать общение с микросервисом?

Нормально ли организовывать одностороннее общение между основным приложением и микросервисом через брокер сообщений?

Общаться через брокер - нормально.
Иметь "основное приложение" - не нормально.
Иметь одни и те же данные в разных сервисах - если таких данных много значит стейт разбит плохо.

Нормально ли делегировать на микросервис работу с БД основного приложения? По факту он будет лишь обновлять какие-то данные, которые изначально основное приложение туда их инициализирует.

Это будет не микросервис а часть основного приложения по сути.

Как эффективно выучить технологии для backend'a?

Saboteur,

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

Через год-два другие люди будут задавать вопросы про "войти в айти", а первые поймут что больше им ловить тут нечего :)

Я там поправил передыдущий свой комментарий. Тостер не создан для сложных тем. Его формат подразумевает простые вопросы с простым однозначным ответом.

Как эффективно выучить технологии для backend'a?

На тостере достаточно неплохих вопросов. Не вина тостера, что англоязычные ресурсы появились раньше и следовательно уже есть ответы на большинство популярных задач.

Но также нужно понимать, что мир не стоит на месте и развивается. Тостер - вполне популярный и крупный ресурс, и он уже состоялся как довольно крупный ИТ ресурсом вопросов-ответов в русскоязычном интернете. Его можно развивать.

Тостер развивается исключительно в сторону вопросов в стиле "войти в айти" и "неосилил документацию", интересных вопросов остаётся лишь меньше, и если раз в месяц таковой вдруг появится, в ответах всё-равно будет чушь.

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

Как эффективно выучить технологии для backend'a?

Saboteur, Гуглить - норма, спрашивать что-то серьёзное на Тостере - гиблое дело, поэтому если человек задающий вопросы на Тостере позиционирует себя выше чем Джун, у меня к нему будет очень предвзятое отношение

Как эффективно выучить технологии для backend'a?

sergeyiljin,

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

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

Как эффективно выучить технологии для backend'a?

sergeyiljin,

Раз вы не можете ничего поменять, тогда
Будем считать, ...

Ну.. Есть истина, есть заблуждения, есть популярные заблуждения, но зачем их дальше в массы двигать если понятно что это заблуждения?

Как эффективно выучить технологии для backend'a?

sergeyiljin,

Ну так докажите куче компаний, что они ошибаются. Напишите статью на Хабре. Съездите на конференции, выступите.

Зачем? Им же и так норм.
Да и я нового то ничего не ввожу и не придумываю, лишь уже изобретённые умными людьми инструменты использую.

Пока рынок всё устраивает, увы, ничего не поменять, а большинство проектов на рынке таковы что им все-равно как дела делать.

Или вы только так, на словах ПРАВИЛЬНЫЙ?

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

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

Как эффективно выучить технологии для backend'a?

sergeyiljin,

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

Ну так раньше большинство считало что земля квадратная, так же как сейчас большинство считает что devops=admin, а с позицией "будем считать так потому что большинство считает так", мы до сих пор бы в средневековье жили :)

На самом деле речь о целесообразности применения технологий, есть 5% кому нужен devops, и они знают что это такое, а есть остальные 95% которым не нужен, но раз технология хайповая, пытаются и себе прикрутить под любым предлогом

Как эффективно выучить технологии для backend'a?

sergeyiljin,

Там для DevOps инженеров те же требования, включая Docker. Что, в компаниях тоже тупые сидят?

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

И ещё по поводу

Что, в компаниях тоже тупые сидят?

Посмотрите на этот замечательный твит - https://twitter.com/fielding/status/324448353180061696
Кратко для случайных читателей: на равне с devops/mvc/agile/oop etc. очень много заблуждений витает вокруг термина REST, и дабы не углубляться в детали, которые вы можете почитать загуглив "REST fielding dissertation" или хотя бы тут, во всем нам известном (о боже!) Google повелись на популярные заблуждения, на что сам автор термина REST(Рой Филдинг) сделал замечание в twitter`е о том что термин REST-endpoint, они используют не корректно

screen

p.s. конечно дока гугла с того времени уже менялась, дока того времени - тут

p.p.s. Но да, людям проще у гугла скопировать чем разобраться.

Как эффективно выучить технологии для backend'a?

sergeyiljin, Ну и к чему тут это?
На Хабре чуши разной навалом, верным оно от этого не становится.

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