у приложения с нормальной архитектурой в основе может быть говнокод

Хм. Архитектура - это решения, которые дорого менять. А уж откуда они появились - какая разница

говнокод тоже не дешево менять. но он не относится к архитектуре

Почему? По какому определению?

по кочану и по кочарыжке

Уровень аргументации понятен, больше вопросов нет.

Да, по всей видимости, два инстанса одного сервиса. А вообще, вопрос не очень простой. Мы когда-то с ним разбирались (в приватной группе), и там все не так очевидно. Совершенно очевидно, что BC не должен шарить данные (кроме случая статистики). А вот по поводу микросервиса - там все не так однозначно, тем более, что есть физические и логические микросервисы. Может быть я републикую как-нибудь всю найденную информацию по этому вопросу у себя в открытом канале, если руки дойдут.

BC - это что в данном случае?

Bounded Context

А я думал высшие силы(

Ну, да, так как в разных BC, теоретически, разное понимание терминов - то шарить данные нереально.
А вот среди микросервисов внутри BC - почему бы и нет?

По идее, паттерн bff не про агрегирование данных, у него немного другой смысл.

Ну, он про подготовку данных для отображения, так что обогащение на нем нормально делать.

Верно, но обогащение данных в этом случае происходит за счёт вызовов других микросервисов в рамках бакэнэко архитекторы. Мы экономим батарею пользователя. Но наши, достаточно дорогие, вызовы никуда не делись. Тем более если ноды с микросервисами могут быть географически распределены по разным датацентрам.

Будет очень интересно.

Наверное, речь идет об этом?
https://docs.microsoft.com/en-us/azure/architecture/patterns/gateway-aggregation

Вот домашняя страничка BFF из первоисточника, если я не ошибаюсь. Агрегация данных очень даже в нем хорошо описана:
https://samnewman.io/patterns/architectural/bff/

И там же есть совет выносить агрегацию из bff )

Много написано, возможно я как-то неправильно интерптерирую контекст.

Если я правильно понял, мы решаем задачу сихнронизации данных между BC и/или между двумя микросервисами в рамках одного BC, с сохранением атономности микросервисов и их баз прежде всего. Эту задачу можно решить несколькокими способами, вот два из них:
1) При событийно-ориентированной архитектуре "зависимый" микросервис, причём не важно, в одном BC или нет, слушает изменения и обновляет у себя некое внутреннее представление. При этом, микросервисы должны публиковать все изменения, что не проблема  при наличии современных pub/sub продуктов. На самом деле мы и так публикуем все изменения, они потом пишутся в лог Hadoop, например, индексируются Эластиком и т.д.
2) Использовать CQRS - то есть микросервисы выставляют адаптированные для чтения представления (read model), которые могут читать другие микросервисы напрямую. Но нужно понимать, что при этом структура этих представлений и параметры подключения к ним становятся частью контракта. В случае EventSourcing выставлюятся не представления, а проекции. @emacsway поправь пожалуйста если я заблуждаюсь.

При этом, в обоих случаях агрегация выполняется в зависимом микросервисе "заказы".

Bff предназначен для формирования "внешнего" API под конкретный клиент (фронт/мобайл), при этом Bff выполняет агрегацию "внутренних" API.  Bff должен минимум логики содержать и  делать только минимум из того, что нужно для "внешнего" API на основе вызовов "внутренних" API. По сути это вариант паттерна Facade. Иначе логика переедет в Bff, то есть всё что мы не сделали в микросервисе "заказы", переедет с большой вероятностью в Bff. Отличный вариант!:)

Почему так. Тут все "пляски" вокруг автономности БД микросервисов. Зачем нужна автономность? Чтобы кто-то с наружи не уронил запросами БД (модель изменения в терминах CQRS) и чтобы микросервис мог произвольно изменять структуру своей БД (своих таблиц при Monolith First). Оба варианта решают задачу автономности модели изменений, а модели чтения итак адаптированы под запросы извне и должны хорошо масштабироваться на чтение.

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

Сложность запросов во 2-м случае невозможно контролировать. Как решение, представления на чтения в инмемори базах/кэше которые просто нельзя нагрузить "олапными" запросами, потому что они не умеют полноценный SQL. А в идеале - отдают данные только по ключу.

И мы конечно понимаем, что в любом случае речь о согласованности в конечном итоге.

И ещё, внимание!!!))) Bff - API под конкретный клиент. То есть Bff может быть несколько. А это значит, что логика агрегации будет дублироваться в разных Bff.