Можно ли изменять несколько агрегатов одной транзакцией? В профессиональной среде существует популярное мнение что нельзя. Этот вопрос затрагивает Vladimir Khorikov в статье "Crossing aggregate boundaries", и говорит, что:
> I hear this guideline a lot as well.
Тоже слышал эту фразу много раз, как правило от тех, кто эту книгу сам не читал. Именно поэтому важно получать информацию из первоисточника, где V.Vernon сопровождает эту информацию еще целым рядом дополнительной информации, в которой он не только допускает, но и рекомендует в некоторых случаях фиксировать несколько агрегатов одной транзакцией. Более того, он раскрывает причины такого правила, а знание причин освобождает от догматизма и опасности впадения в Cargo Cult.
Но, ок, а как все-таки обеспечить соблюдение инвариантов в условиях отсутствия поддержки строгой транзакционной согласованности?
Недавно, как раз обсуждал этот вопрос в одной из заметок.
Одним из решений является "Data, context, and interaction (DCI)" (от авторов MVC).
Подробное описание приводится в главе "Chapter 9. Coding it Up: The DCI Architecture" книги "Lean Architecture: for Agile Software Development" 1st edition by James O. Coplien, Gertrud Bjørnvig.
Можно посмотреть на примере Golang-реализации перевода денежных средств с одного счета на другой счет, с использованием DDD & DCI (доступна также python-версия).
Также стоит выделить в этом вопросе интервью "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts, где решение подобных задач возлагается на Process Manager Pattern.
Другие варианты приводятся в заметке.
#DDD #DistributedSystems
> I hear this guideline a lot as well.
Тоже слышал эту фразу много раз, как правило от тех, кто эту книгу сам не читал. Именно поэтому важно получать информацию из первоисточника, где V.Vernon сопровождает эту информацию еще целым рядом дополнительной информации, в которой он не только допускает, но и рекомендует в некоторых случаях фиксировать несколько агрегатов одной транзакцией. Более того, он раскрывает причины такого правила, а знание причин освобождает от догматизма и опасности впадения в Cargo Cult.
Но, ок, а как все-таки обеспечить соблюдение инвариантов в условиях отсутствия поддержки строгой транзакционной согласованности?
Недавно, как раз обсуждал этот вопрос в одной из заметок.
Одним из решений является "Data, context, and interaction (DCI)" (от авторов MVC).
Подробное описание приводится в главе "Chapter 9. Coding it Up: The DCI Architecture" книги "Lean Architecture: for Agile Software Development" 1st edition by James O. Coplien, Gertrud Bjørnvig.
Можно посмотреть на примере Golang-реализации перевода денежных средств с одного счета на другой счет, с использованием DDD & DCI (доступна также python-версия).
Также стоит выделить в этом вопросе интервью "Modeling Uncertainty with Reactive DDD" by Vaughn Vernon reviewed by Thomas Betts, где решение подобных задач возлагается на Process Manager Pattern.
Другие варианты приводятся в заметке.
#DDD #DistributedSystems