Сергей Соловьев

Чтобы уметь их сравнивать.
Если использовать твое решение (без времени), то будет верным только 1 узел всегда (если в этом случае сравнение будет иметь смысл).

Отвечу на вопрос так: ядро DDD - представление бизнес-логики в коде. Добавляются промокоды, уровни скидок, подписки и т.д. - все это меняет бизнес-логику. Это нельзя просто просто взять и убрать, т.к. грубо говоря, под эти дела завели отдельные документы (юридически оформили уровни скидок, промокоды и т.д.). Соответственно и твоя доменная сущность должна измениться, так как она - отражение реального мира, а реальный мир изменился.

В секции "Вопрос: ..." у тебя 3 вопроса, но смысл у них одинаковый: как правильно писать код так, чтобы было легко добавлять изменения?
На абстрактный вопрос отвечу абстрактно - зависит. Для каждого случая надо искать свое решение, нет единого правильного, в любом случае тебе будет нужно изменять код, чтобы соответствовать условиям реального мира.

P.S. сделаю замечание по поводу этой фразы:

Также, подписки находятся в отдельном микросервисе, имеют свою БД и никак не связаны с сущностью пользователь.

Тут явно это не говорится, но мне кажется, что ты разделяешь микросервисы по сущностям. Это плохой подход, так как ведет к головным болям, которые приводят к подобному (заданному) вопросу. Запомни: микросервисы надо разделять по бизнес-задачам, а не сущностям (иначе получаются вот такие crud сервисы, знающие друг о друге).
Начни с этой статьи, и копай дальше. Иногда вопросы кода надо решать на уровне архитектуры системы.

Миллион элементов в json - это сильно (жирно).
Предлагаю следующий вариант:
- В качестве брокера использовать любой брокер сообщений/менеджер очередей с ACK/NACK механизмом (Redis Streams, RabbitMQ, Kafka)
- Все json разбиваем на 2 категории - большие и маленькие в зависимости от размера (кот. поддерживает брокер)

Алгоритм будет следующий:
Producer:
- Приходит запрос с json
- Если json маленький, то отправляем в брокер напрямую
- Если json большой, то сохраняем его в отдельную БД и получаем ID этой записи, в брокер отправляем ID этой записи

Consumer:
- Получает сообщение из брокера
- Если json содержится в сообщении (когда маленький), то сохраняем в БД
- Если json был большим и передан ID из БД, то читаем этот JSON из временный БД и сохраняем в целевую БД
- Коммитим сообщение

Пример такого запроса:

// Маленький объект
{
   "data": {
       "key": "value"
    },
    "id": null
}

// Большой объект
{
    "data": null,
    "id": 13123123
}

P.S. название паттерна хранения большого объекта во внешнем хранилище и передача только его id не помню

Самый популярный фреймворк для SSO - OAuth.
Про него много где уже писали. Например, вот некоторые ссылки:
- https://habr.com/ru/articles/77648/
- https://habr.com/ru/companies/vk/articles/115163/
- https://oauth.net/2/

Также есть еще и OpenID Connect. Это фреймворк построенный вокруг OAuth:
- https://habr.com/ru/companies/nixys/articles/566910/
- https://openid.net/developers/how-connect-works/

Поймешь как они решают эту проблему - поймешь как решить свою.
На вопрос прямого ответа не дам - много букв

Как по мне, для MVP достаточно будет монолита. + т.к. модели практически одинаковые, то будет проще.
Если выстрелит, то сделай рефакторинг под модульный монолит, а потом и микросервисы.

Ну я вроде и рассказал, что это противоречит тому же SOLID

Проектировать API надо по требованиям предметной области.

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

а почему я не могу в API сделать метод DELETE и в него передавать и тип объекта, и его id

Почему нет? Если объекты создаются динамически, а не предопределены, то передавать их тип - хорошая идея.
Все зависит от проблемы.

Есть где кратко изложенная теория по этому поводу?

Вряд-ли. Все зависит от проблемы/предметной области.
Могу посоветовать алгоритм:
1. Выявить функциональные требования к системе
2. Представить их в виде условных функций
3. Переписать их в виде вызовов API (за основу можно взять готовые паттерны проектирования: REST, SOAP и т.д.)

Посмотрите на API VK или Telegram. Это не REST, но тоже удобно

Anti-Corruption Layer - это понятие из DDD. Оно обозначает слой (это может быть отдельный сервис или функция валидации), который проверяет запрос на корректность.

Адаптер - это больше паттерн проектирования, который, грубо говоря, трансформирует запрос из одного формата в другой. Например, из XML в JSON, или если стоит прокси, то превращает `X-Redirected-From` в `Redirected-From` в HTTP заголовках.

Адаптер может выполнять роль Anti-Corruption Layer и наоборот