неа, а что не так?

не знаете почему так происходит? я погуглил но ничего не понял
https://pastenow.ru/442ecc3d4e28c870e715dda6ea3e4a4b

там прям в ошибке написано, в чем проблема. Проверь ключ volumes

докер считает, что пытаешься замаунтить папку в файл внутри контейнере (или наоборот).
В указаном выше ключе композовского ямла посмотри на слеши после имени файла, и вообще убедись, что config/database.yaml существует и не является папкой внезапно

ок, спасибо.
Я просто не devops, новичок в docker

Поделитесь, пожалуйста, как можно развивать архитектуру продукта без Самого Главного Архитектора?

Кто инициирует и следит за изменениями архитектуры, когда они явно не попадают в области ответственности уже существующих команд? Кто принимает решение о создании новой группы сервисов? И т.д.

Как не погрязнуть в хаосе и отсутствии понимания/документации?

что значит "развивать архитектуру продукта" ? Продукт они типа бизнес дривен, а развитие архитектуры это уже подстройка под реалии текущие.
Так или иначе обычно есть человек \ группа людей, технических на которых сваливаются бизнесовые задачи, и которые грумятся потом либо лично им либо командой, либо инициативной группой.

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

если вы думаете "чтобы нам такого сделать крутого в архитектуре продукта" - кажется вам нечем заняться )

Кейс. Продукт большой, поделен на направления. У каждого направления свой PO. У PO появлятся идея. Команда понимает, что это не вписывается в разрабатываемые ими сервисы. И вот что дальше происходит?
А если у кого-то уже реализован похожий функционал? Как уже существующим сервисам (от других команд) начать работать с новым?

Как решаются задачи Самого Главного Архитектора, когда его нет?

Возможно банальщина, но может собрать тех-лидов/PO всех команд в чатике и обсудить. Если функционала нет - кто-то берет в работу (ну или если никто не берет, значит бизнесу не очень то и надо). Если есть и удовлетворяет запросу - утверждаем интерфейс?

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

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

А есть ли “лучшие практики” для принципов?

где-то видел, поищу

Я еще нашему Юре такой же вопрос задал. Тоже дошли до идеи, что должны быть пошаренные принципы, иначе не взлетит.

Теперь интересно как эти принципы могут выглядеть. Если для самого архитектурного решения есть, например, DDD. То для организации процесса архитектурного изменения я подобного не видел

вот, что у меня в закладках есть https://adr.github.io/

вот еще https://www.agilealliance.org/resources/experience-reports/distribute-design-authority-with-architecture-decision-records/ тут прям примерчики

Спасибо

Здравствуйте!

Можно ли разместить вакансию?