один расход может (и должен) иметь одну категорию. Если у сервисов есть свои собственные базы данных, как я могу гарантировать, что у данного расхода есть существующая категория?
В общем, нет. То есть информация, которая должна быть согласованной, должна храниться в одном и том же месте (т. Е. В одной и той же «микросервисной»). Вы распределяете данные по нескольким базам данных только тогда, когда они не должны быть согласованными.
Один из возможных компромиссов, который иногда является приемлемым, заключается в том, что мы можем хранить в базе данных расходов кэшированную копию информации о категории. Это позволяет подумать о добавлении ограничений на то, что данные о расходах должны соответствовать кэшированной копии данных категории, при условии, что вы можете справиться с тем фактом, что копия данных категории будет устаревшей и может быть признана недействительной в результате внесенных изменений. к данным категории.
Но обеспечение ссылочной целостности имеет проблему с условиями гонки;Я отправляю расходы в категорию, которая «действительно» существует, но еще не появилась в кэшированной копии. Что должно произойти? «Разница во времени в микросекундах не должна влиять на основные бизнес-процессы».
Еще один вид компромисса - моделирование времени - во вторник в расходах можно использовать категорию, которая быладействует во вторник, даже если в среду он больше не действителен. Таким образом, служба расходов может приостановить решение, пока не узнает, действительна ли категория в соответствующее время. Это имеет смысл, когда изменения в политике расходов планируются заранее.
Другим компромиссом может быть реорганизация реализации ваших бизнес-возможностей, чтобы все поведения, связанные с категорией, выполнялись службой, котораяуправляет этими данными. Служба расходов будет знать об идентификаторе, но совсем немного.
Волшебства нет - распределенные системы требуют компромиссов.