Александр Межов
Заметки про ИТ-архитектуру и разработку | Мой Telegram - https://t.me/arch_and_dev | Сайт - https://amezhov.ru/
Всё так. Спасибо за дополнение. :)
Спасибо за дополнение! Верно подмечено.
Да, согласен, это можно встретить очень часто :)
Спасибо, обязательно посмотрю! :)
Здравствуйте!
Спасибо за активность и развернутую обратную связь!
Соглашусь с вами в том моменте, что преждевременное усложнение - это крайне плохо. В идеале хорошо, если агрегат доменной модели целиком хранится в рамках одного хранилища, которое поддерживает транзакции. В остальном есть нюансы, о которых скажу ниже.
В первую очередь хотелось бы сказать, что моя заметка - это ответ на поставленный вопрос. Считайте, что архитектурное решение уже принято без нас с вами, остаётся решить технические детали. Почему было принято такое решение, где компоненты системы должны общаться асинхронно через брокер, да еще с высокими гарантиями доставки, остаётся за рамками поставленного вопроса. Думаю, что на то были веские причины.
Во-вторых, как бы нам с вами не хотелось, но мир движется в сторону распределенных систем и гетерогенному хранению данных. И это факт. Поэтому вопросы согласования данных в распределенных системах оправданно актуальны. В связи с этим инженеры вынуждены разбираться во всех этих нюансах.
В-третьих, в более сложных случаях мы вынуждены идти на декомпозицию системы, организуя ее в виде набора взаимодействующих служб. И иногда нам нужны и гарантии доставки, и порядок событий, и многое другое. Это трудно отрицать, т.к. в противном случае мы скатываемся к примитивизму, где есть только чёрное и белое, правильное и неправильное. Если бы все было так просто. Мы принимаем то или иное архитектурное решение на основании совокупности факторов, не зная которые давать оценочные суждения о удачности решения, как минимум, неправильно. Всегда ли вы можете использовать только ACID-хранилище, в которой помещается весь агрегат? Нет, не всегда, и я это могу сказать с абсолютной уверенностью. Есть предметные области, где важны гарантии согласованности, но документы хранятся в гетерогенном хранилище. Например, медицина. Часть документа хранится в РСУБД, а часть может храниться в BLOB-хранилище. И тут нет возможности использовать только ACID, тут придется использовать либо 2PC (распределенные транзакции), либо механизм повествований (saga).
Наконец, вы сказали, что без ACID нельзя добиться гарантий, согласованности и надёжности. Дело в том, что можно. Шаблон Transactional Outbox (и Inbox), ссылка на который дана в статье, как раз позволяет этого добиться. Конечно, есть нюансы в виде eventual consistency, но они также решаемы.
Спасибо за комментарий. Согласен с вами. На ранних этапах развития это особенно ценно, т.к. по разным причинам есть высокая степень неопределенности. Единственное, что можно добавить, это предусмотреть возможные варианты расширения этих границ.