Спасибо за комментарий! Если вы для себя, как для руководителя разработки, сможете сформулировать значимость и структурировать управление техническим долгом, довести свое видение до бизнеса будет значительно легче.
Денис, потому что ChatGPT скомпилировала эту информацию на основе моей статьи. Обратите внимание, что в конце она ведет на мой канал. Аналогичную статью я публиковал ранее на vc.ru. И, судя по всему, ChatGPT теперь учится намного быстрее)
Александр, спасибо за комментарий! Да, соглашусь с вами. GPT на сегодня умеет прекрасно структурировать информацию и формировать ее в виде плана действий. И в этом моя статья похожа. Управление техническим долгом является не только моей головной болью, но и головной болью моих коллег. Сформировав решение в своей голове, я решил поделиться им с сообществом в формате структурированного набора рекомендаций.
Денис, я открыл вашу ссылку и не нашел ничего общего с моей статьей. Эту статью я писал из своей головы, не опираясь на чьи-либо труды. В ChatGPT я вообще не ходил. Так что нет, не извиняю. Уже откровенно начинает раздражать попытка выдать личный труд человека за работу ChatGPT.
Спасибо за комментарий! Вы правы. Выбор инструмента должен быть обдуманным. Этого вопроса я коснулся в третьей части https://habr.com/ru/articles/748410/
Большое спасибо за отличный вопрос! Нет, здесь не имеется в виду транзакция базы данных. Транзакция базы данных - это уровень реализации. Агрегат определяет границы согласованности транзакций. Когда транзакция уровня агрегата передается в базу данных для сохранения, все составные части в пределах этого агрегата должны быть непротиворечивыми и соотвествовать бизнес-правилам. Под транзакцией здесь подразумевается способ изоляции изменений агрегата и поддержки бизнес-инвариантов. Бизнес-инварианты должны поддерживаться с целью обеспечения согласованности последующих (во времени) бизнес-операций. Не имеет значения, как будет осуществлен контроль этого требования - с помощью атомарной транзакции базы данных или других средств, - состояние агрегата должно быть безопасным, гарантирующим правильные переходы состояний. Возвращаясь к вопросу о необходимости обновления нескольких агрегатов в рамках одной "бизнес-транзакции". Здесь скорее речь об итоговой согласованности. Методы ее достижения отличаются для разных типов интеграции. Я приведу пример для интеграции с рассылкой сообщений (другие варианты подробно описаны в книге Implementing Domain-Driven Design в рамках связывания контекстов). Обеспечить итоговую согласованность в случае асинхронной передачи данных можно посредством публикации событий предметной области. Агрегат после изменения своего внутреннего состояния публикует событие, которое получают и обрабатывают агрегаты-потребители. Цепочка этих действий должна приводить к итоговой согласованности в системе. Разумеется, доставка события в таком случае должна быть гарантированной. В заключении хочу подчеркнуть мысль о том, что явного запрета на одновременное обновление нескольких агрегатов здесь не предполагается. Важно обеспечить два типа согласованности: транзакционную согласованность агрегата и итоговую согласованность. Если мы хотим выполнить одновременное обновление нескольких агрегатов для достижения итоговой согласованности, то важно убедиться, что внутренняя (транзакционная) согласованность каждого из них не будет нарушена. Каким образом будет обеспечен тот или иной уровень согласованности - вопрос реализации.
Спасибо за комментарий! Действительно, при написании статьи я полагался на труды Сэма Ньюмана. Хоть и не полностью. В дальнейшем постараюсь использовать большее количество источников.
Спасибо за комментарий! Да, обсуждал. Новое видение сформировано не без участия психолога.
Спасибо за слова поддержки!
Спасибо за комментарий! Если вы для себя, как для руководителя разработки, сможете сформулировать значимость и структурировать управление техническим долгом, довести свое видение до бизнеса будет значительно легче.
Замечательно, что у вас получилось!
Спасибо за комментарий. Я описал диагноз, постановку проблемы и предложил решение. Все кратко и по сути.
Денис, потому что ChatGPT скомпилировала эту информацию на основе моей статьи. Обратите внимание, что в конце она ведет на мой канал. Аналогичную статью я публиковал ранее на vc.ru. И, судя по всему, ChatGPT теперь учится намного быстрее)
Александр, спасибо за комментарий! Да, соглашусь с вами. GPT на сегодня умеет прекрасно структурировать информацию и формировать ее в виде плана действий. И в этом моя статья похожа. Управление техническим долгом является не только моей головной болью, но и головной болью моих коллег. Сформировав решение в своей голове, я решил поделиться им с сообществом в формате структурированного набора рекомендаций.
Денис, я открыл вашу ссылку и не нашел ничего общего с моей статьей. Эту статью я писал из своей головы, не опираясь на чьи-либо труды. В ChatGPT я вообще не ходил. Так что нет, не извиняю. Уже откровенно начинает раздражать попытка выдать личный труд человека за работу ChatGPT.
Спасибо за комментарий! Вы правы. Выбор инструмента должен быть обдуманным. Этого вопроса я коснулся в третьей части https://habr.com/ru/articles/748410/
Хорошая аналогия! Как говорится, ничто не ново!
Большое спасибо за отличный вопрос!
Нет, здесь не имеется в виду транзакция базы данных. Транзакция базы данных - это уровень реализации. Агрегат определяет границы согласованности транзакций. Когда транзакция уровня агрегата передается в базу данных для сохранения, все составные части в пределах этого агрегата должны быть непротиворечивыми и соотвествовать бизнес-правилам. Под транзакцией здесь подразумевается способ изоляции изменений агрегата и поддержки бизнес-инвариантов. Бизнес-инварианты должны поддерживаться с целью обеспечения согласованности последующих (во времени) бизнес-операций. Не имеет значения, как будет осуществлен контроль этого требования - с помощью атомарной транзакции базы данных или других средств, - состояние агрегата должно быть безопасным, гарантирующим правильные переходы состояний.
Возвращаясь к вопросу о необходимости обновления нескольких агрегатов в рамках одной "бизнес-транзакции". Здесь скорее речь об итоговой согласованности. Методы ее достижения отличаются для разных типов интеграции. Я приведу пример для интеграции с рассылкой сообщений (другие варианты подробно описаны в книге Implementing Domain-Driven Design в рамках связывания контекстов). Обеспечить итоговую согласованность в случае асинхронной передачи данных можно посредством публикации событий предметной области. Агрегат после изменения своего внутреннего состояния публикует событие, которое получают и обрабатывают агрегаты-потребители. Цепочка этих действий должна приводить к итоговой согласованности в системе. Разумеется, доставка события в таком случае должна быть гарантированной.
В заключении хочу подчеркнуть мысль о том, что явного запрета на одновременное обновление нескольких агрегатов здесь не предполагается. Важно обеспечить два типа согласованности: транзакционную согласованность агрегата и итоговую согласованность. Если мы хотим выполнить одновременное обновление нескольких агрегатов для достижения итоговой согласованности, то важно убедиться, что внутренняя (транзакционная) согласованность каждого из них не будет нарушена. Каким образом будет обеспечен тот или иной уровень согласованности - вопрос реализации.
Спасибо за комментарий! Действительно, при написании статьи я полагался на труды Сэма Ньюмана. Хоть и не полностью. В дальнейшем постараюсь использовать большее количество источников.