Микросервисы DDD CQRS

Я считаю, что он тесно связан с другими службами и не является независимым.

да.

Вы можете улучшить независимость, тщательно продумав режимы отказа; как должны вести себя элементы пользовательского интерфейса, когда соответствующий центр данных недоступен. Вы можете, например, сделать так, чтобы домашняя страница просто отображала сообщение «данные недоступны», если удаленный орган не отвечает своевременно. Или вы можете сделать так, чтобы на домашней странице отображалась кэшированная копия некоторых устаревших данных. Может даже иметь смысл всегда отображать ответ с использованием кэшированных данных, при этом обновления кэша происходят в фоновом режиме.

Существуют методы, которые можно использовать для уменьшения связи между службами.
Один из подходов описан Уди Даханом в разделе Техники компоновки пользовательского интерфейса. Его идея заключается в том, что вы используете элемент, например виджет, для инкапсуляции логики отображения и режима отказа.

Лежащая в основе механика на самом деле не так уж и отличается; виджет имеет все те же проблемы, что и раньше, когда данные недоступны. Но что он делает, так это разделяет две проблемы (что вы делаете, когда виджет недоступен, что вы делаете, когда данные недоступны), которые принадлежат разным командам: команда домашней страницы решает, что делать. когда виджет недоступен (возможно, используется кешированная копия), команда обслуживания решает, что делать, когда виджет не может получить доступ к резервным данным (возможно, виджет имеет собственный кеш устаревших данных).

Нет никакой магии; у вас есть распределенная система, и следствием этого является то, что вы должны учитывать в своем проекте тот факт, что удаленные процессы не всегда будут доступны.