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

Если я правильно понял, мы решаем задачу сихнронизации данных между 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. А в идеале - отдают данные только по ключу.

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

Да, но я пока не увидел аргументов  о том, что эти данные нужны сервису, а не клиенту (может быть я просто невнимательно смотрел). Наверное, именно поэтому, @dphil и заговорил о BFF.

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

Иными словами, какая-то часть клиентских данных ВСЕГДА является частью заказа. То есть, какая-то часть клиентских данных должна входить в состав агрегата  "Заказ", но этот агрегат ими не владеет, а только использует.

В случае с Bff мы "собираем" заказ в Bff, а не в микросервисе "Заказ" (условно).

Чтобы использовать, нужно либо подписаться и хранить копию (вариант 1), либо ходить за ними, когда нужно. Ходить можно по API или непосредственно за данными. Непосредственно за данными лучше ходить к представлению на чтение (вариант 2).

Мне кажется, что тут пошла терминологическая путаница.
@emacsway под "клиентом" подразумевал "пользователя сервиса", а ты - "клиентские данные".

А как её избежать. Клиенту (мобилке/вебке) нужны в составе заказа данные Клиента (человека)

Как мне кажется, в контексте всё же можно разделить

Я обычно говорю "фронтенду нужны данные Клиента" )

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

Когда мы говорим Bff, значит есть и другой потребитель сервиса (Клиент), а не только фронт. Иначе смысла в Bff нет и достаточно General purpose API

Ну, иногда бывает ровно один потребитель и под него делаем bff - потому что именно под него, а не под произвольного потребителя (т.е. API точно не generic).

Но вообще вопрос про "сервису нужны данные Клиента" сильно зависит от решения.
Я вот делю микросервисы внутри контекста на "доменные" (по сути хранилища с минимальной логикой) и сценарные (оркестрация изменений). Первые вообще друг про друга ничего не знают, вторым часто нужны данные из кучи сервисов, включая чужих.
Ну и bff (для разных потребителей, включая и API).
Но это я просто не люблю событийную модель внутри контекста.

Bff когда несколько потребителей разных, мначе это просто General purpose API. Почему? Потому что ВЕСЬ API нужен единственному клиенту.

Хм. Для меня разница в другом. bff - когда я точно знаю потребителя API. А General Purpose API - когда я его вообще не знаю.
Так что может быть и BFF для единственного потребителя.
При проектировании разница очень заметна )