hAnthor

Вообще на самом деле джанго можно сделать аля-микросервисным если рассматривать каждое приложение как отдельный микросервис.
В Джанго можно подключить для любой модели отдельную базу данных которая может находится на отдельном сервере или другом порту.
Всё что требуется добавить в модель следующие:

class MyModel(Model):
    class Meta:
        using = 'default'  # дефолтная база из DATABASES из settings.py

Использование отдельных баз данных это дело одно, но вам скорее всего хотелось бы чтобы каждое приложение работало на отдельном порту, это тоже не проблема, в каждом приложении создайте systemd.service который запустит экземляр на другом порту и делайте жесткую ссылку в systemd/system, после через nginx проксируйте по location на порт приложения.
Чисто так технически можно перенести экземпляры на разные серверы и поправить конфиги.
Важно чтобы секретный ключ был один и тот же везде, иначе будет много проблем, по безопасности всё ок если не раскрывать его третьим лицам.
Как вариант секретный ключ и другие данные можно хранить в .env и подгружать их в settings.py.
Если хотите сохранить чистоту коду, то экземляры можно раскидать по папкам, в каждой из них набросать по минималке README.txt с инфой на каком порту запущено, какие команды для остановки и перезапуска, какие паки нельзя трогать а какие можно, можно только ту в которой висит приложение а все остальные папки которые не взаимодействуют из этого приложения можно снести.

В общем какой-то такой вариант можно реализовать, но я бы рекомендовал оставить как есть и по возможности старые сервисы переписывать на микросервисы FastAPI а новые эндпоинты сразу пилить на нём.

Смотри. Уже прошло время когда все пилили монолиты на микросервисы. Щас пошло переосмысление.
Объективно есть 2 причины пилить. Первое - организационная. Команда по какой-то причине не хочет
или не может поддерживать приложение. Или там что-то с бизнесом. Слияние. Поглощение. Передача
проекта другой команде в поддержку. Тогда берут и ставят задачу раздела отвественностей.
Конвей про это писал еще.

И второе - это баланс нагрузки и децентрализация. Про failover тут еще даже речи нет. Это
тяжелая тема и распилить монолит так чтобы его части были отказоустойчивы очень трудно. Более
того в случае синхронных взаимодействий между частями микросервисов может быть даже падение
перформанса. Да. Теоретики которые там пишут восторженные отзывы - совершенно игнорируют
накладные на RPC. И не упоминают что в монолите цена RPC была равна нулю. Иногда RPC заменяют
на MQ - но это новая архитектура и это надо полностью переделывать бизнес.

И что делать с базой данных? Это тот еще вопрос. Я почти готов спорить что вы базу пилить не будете.
И что в результате будет? Иммитация микро-сервисов? Где слабая связность?

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

Но имеет смысл сделать модуляризацию монолита. Например что там...

application
- sales
- hiring
- userprofiles

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

Видимо из вселенной C++ Вы к нам заглянули. Гуглите на тему bound/unbound methods

1. В теле методов нет неявного присваивания аттрибутам объекта.

self.x = 1 — присваивает значение 1 аттрибуту объекта.
x = 1 — присваивает значение 1 локальной переменной (даже если присваивание происходит в методе класса).

2. Как Вы сами написали, параметр self подставляется автоматически, когда метод вызывается для объекта. Поэтому, при вызjве метода с двумя переменными, ему на самом деле передаётся три (и он должен уметь принимать три аргумента).

3. Когда объявляете метод, который будет вызываться для экземпляра класса.

Очень рекомендую почитать эти доки, прежде чем дальше разбираться с языком:

- https://docs.python.org/2/reference/datamodel.html
- https://docs.python.org/2/tutorial/classes.html
- https://docs.python.org/2/reference/executionmodel.html