Это происходит в контексте распределенных вычислений. Имеется служба A, которая владеет базой данных и предоставляет API для обновления сущностей в этой базе данных.
С течением времени сервис развивался, и мы собираемся добавить к нему сложную возможность. Эта возможность может быть выделена в отдельный сервис. Но она обновляет ту же самую сущность, которой владеет сервис A.
Теперь то, на что я не могу найти окончательного ответа, это то, должна ли новая служба B использовать API службы A для обновления сущности или ей следует разрешить прямой доступ к БД.
По моему мнению, поскольку общий код находится в библиотеке, и мы просто меняем место выполнения кода, я не вижу смысла в использовании API.
В целом, мои вопросы таковы:
Действительно, вариант 2 (прямой доступ к БД) делает неясным право собственности на разделяемые сущности и ответственность за их неизменность.
В долгосрочной перспективе риски обслуживания возрастают. Типичным примером является обновление свойства в одной службе, которое не запускает некоторые обновления согласованности, необходимые для свойств, важных для другой службы. Распределение обновления между сервисами может не решить проблему из-за проблем с транзакционной согласованностью.
Вы можете сохранить ситуацию прямого доступа к базам данных чистой, используя общую библиотеку. В этом случае вы должны синхронизировать релизы и развертывание обоих сервисов (coupling). Или же вы можете рассмотреть возможность обеспечения владения сущностями и развязки, например, с помощью микросервисного подхода.