С прошлого воскресенья вы задали несколько классных вопросов — пора на них ответить!

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

Первый вопрос Как лучше организовать файловую структуру на сервере для микросервисов?

Тут нет никакого секрета. Каждый микросервис — это отдельное приложение, и логично, что оно должно быть изолировано от остальных. Оптимальное решение (на мой взгляд) — создать на сервере отдельную директорию для всего проекта, а внутри неё разместить папки каждого сервиса.

В каждой папке — свой docker-compose.yaml, свои конфиги, переменные окружения и так далее. Чтобы микросервисы могли «видеть» друг друга, достаточно подключить их к одной общей Docker-сети, например, к сети основного приложения. Так они смогут взаимодействовать по внутренним DNS-именам.

Дополнительно, в корневой директории можно создать общий docker-compose.yaml, который будет объединять docker-compose-файлы всех сервисов через extends или services, при этом каждый сервис останется независимым.

Второй вопрос Есть проект на фастапи, в каком слое надо написать бизнес-логику? Допустим проект "обмен валют", самый главный скрипт, где написан код пересчет курса валют, если в джанго это будет views, то здесь какой?

Неважно, FastAPI это, Django или бот на aiogram — слои (или хотя бы модули) стоит разделять по их логическому назначению. Если взять архитектуру из моих статей по FastAPI, у нас есть модуль routes.py, который отвечает только за приём запроса и отправку ответа. Всё, что происходит между этими действиями, выносится в отдельный модуль services.py. Именно там выполняется основная логика обработки запроса.

Есть также более низкий слой — managers.py, который отвечает только за работу с базой данных.

Такой подход делает код понятнее: ты всегда знаешь, что логика лежит в services.py, работа с БД — в managers.py, а маршруты — в routes.py. Это и есть разделение ответственности: каждый слой занимается своей задачей. Архитектурных вариантов много, но суть остаётся одной — код должен быть структурированным и легко поддерживаемым.

В этом посте были ссылки, но мы их удалили по правилам Сетки