Меня больше всего заинтересовал два последний пункт:
Показать пример unit-экономики, разделения продуктовых фич, расчета стоимости разработки и содержания проекта на разных языках программирования. (Опираться буду на PHP и Golang)
Вам нужен ментор/наставник. Сам помню как долго въезжал в сложные технологии в начале своей карьеры. Иногда прям со скрипом. А когда разобрался, то понял что блин самое сложное это понять общий замысел, а это же на пальцах можно объяснить - дать базу, каркас знаний, а дальше уже самостоятельно наращивать. Но у меня не было ментора и я шёл долгим путём. А своим ученикам я так и делаю: даю основу/каркас и карту знаний - что дальше нужно самостоятельно изучить. И ещё реально круто, когда есть человек который поможет решить проблемы выходящие сильно дальше границ текущих знаний, как с сервером в вашем случае, для эксперта это всего лишь бордюр, для новичка высокая стена. Ищите ментора. У хабра вроде сервис есть на эту тему где можно людей поискать.
На тему DDD есть много отличных статей, в тч на русском. Не обязательно читать красную книгу чтобы вникнуть, я собственно со статей начинал. Для меня чистый код - это когда его легко читать, как хорошую книгу, а это не выполняется когда взаимосвязанные вещи разбросаны по разным веткам путей в файловой системе.
Аналогия очень простая в жизни есть: представь, что у тебя бизнес и есть разные виды документов - договора покупки с поставщиками, договора продажи с клиентами, транспортные накладные (необходимы для транспортировки груза), дополнительные соглашения с кем угодно, квитанции об оплате и т.д... И вот как лучше их хранить - складывать по типу (как я только что перечислил) или лучше все документы регулирующие отношения с каждой конкретной организацией хранить в своей папке (и при необходимости уже внутри неё делить по типам)? В первом случае чтобы разобраться в вопросе придётся рыться в разных папках, каждый раз вчитываясь и пытаясь понять оно или не оно, а во втором случае находишь одну папку и в ней всё, что нужно. По-моему очевидно второй вариант лучше. Причём этот пример никак не касается DDD.
То, что второй вариант (класть все в App/Service) более стандартный (наверное в силу того, что так в симфони гайдах написано) не делает его более правильным.
Я не раз встречался с проектами, которые начинали свою структуру именно по такому шаблону... Как итог, с этим становится невыносимо грустно работать: в директории Entity дохреналиард файлов с сущностями и вложенных директорий с ними же, аналогичная история с Service, DTO, Repository и др. В итоге все файлы компонентов перемешаны, нет чёткого понимания где определённый класс может быть заюзан (буквально через use), а где нет. А уж в плане навигации по коду проекта так совсем не весело скролить по несколько экранов вверх-вниз (ведь раскрывая директорию выпадает куча файлов). Все эти лишние сложности исчезают, когда логически взаимосвязанный код лежит рядом, в одном корневой неймспейсе (домене, модуле, пакете).
Симфони гайды я думаю на новичков рассчитаны, чтобы не усложнять погружение в и без того не простой фреймворк рассуждениями про контексты, домены и тд. Когда пострадаете с моё с разросшимися проектами основанными на стандартном шаблоне, то я думаю поймёте меня :)
DDD в помощь, но без фанатизма, во всем важна золотая середина.
Меня больше всего заинтересовал два последний пункт:
Мне будет интересно почитать.
Вам нужен ментор/наставник. Сам помню как долго въезжал в сложные технологии в начале своей карьеры. Иногда прям со скрипом. А когда разобрался, то понял что блин самое сложное это понять общий замысел, а это же на пальцах можно объяснить - дать базу, каркас знаний, а дальше уже самостоятельно наращивать. Но у меня не было ментора и я шёл долгим путём. А своим ученикам я так и делаю: даю основу/каркас и карту знаний - что дальше нужно самостоятельно изучить. И ещё реально круто, когда есть человек который поможет решить проблемы выходящие сильно дальше границ текущих знаний, как с сервером в вашем случае, для эксперта это всего лишь бордюр, для новичка высокая стена. Ищите ментора. У хабра вроде сервис есть на эту тему где можно людей поискать.
На тему DDD есть много отличных статей, в тч на русском. Не обязательно читать красную книгу чтобы вникнуть, я собственно со статей начинал. Для меня чистый код - это когда его легко читать, как хорошую книгу, а это не выполняется когда взаимосвязанные вещи разбросаны по разным веткам путей в файловой системе.
Аналогия очень простая в жизни есть: представь, что у тебя бизнес и есть разные виды документов - договора покупки с поставщиками, договора продажи с клиентами, транспортные накладные (необходимы для транспортировки груза), дополнительные соглашения с кем угодно, квитанции об оплате и т.д... И вот как лучше их хранить - складывать по типу (как я только что перечислил) или лучше все документы регулирующие отношения с каждой конкретной организацией хранить в своей папке (и при необходимости уже внутри неё делить по типам)? В первом случае чтобы разобраться в вопросе придётся рыться в разных папках, каждый раз вчитываясь и пытаясь понять оно или не оно, а во втором случае находишь одну папку и в ней всё, что нужно. По-моему очевидно второй вариант лучше. Причём этот пример никак не касается DDD.
То, что второй вариант (класть все в App/Service) более стандартный (наверное в силу того, что так в симфони гайдах написано) не делает его более правильным.
Я не раз встречался с проектами, которые начинали свою структуру именно по такому шаблону... Как итог, с этим становится невыносимо грустно работать: в директории Entity дохреналиард файлов с сущностями и вложенных директорий с ними же, аналогичная история с Service, DTO, Repository и др. В итоге все файлы компонентов перемешаны, нет чёткого понимания где определённый класс может быть заюзан (буквально через use), а где нет. А уж в плане навигации по коду проекта так совсем не весело скролить по несколько экранов вверх-вниз (ведь раскрывая директорию выпадает куча файлов). Все эти лишние сложности исчезают, когда логически взаимосвязанный код лежит рядом, в одном корневой неймспейсе (домене, модуле, пакете).
Симфони гайды я думаю на новичков рассчитаны, чтобы не усложнять погружение в и без того не простой фреймворк рассуждениями про контексты, домены и тд. Когда пострадаете с моё с разросшимися проектами основанными на стандартном шаблоне, то я думаю поймёте меня :)
DDD в помощь, но без фанатизма, во всем важна золотая середина.
А можно ссылку на выступление?