Скрам - это новый ватерфол, который все полюбили, ведь любить нужно новое и модное, а старое и не модное принято презирать. Скрам это лекарство от всех болезней, однако оно не помогает, если его неправильно принимать. Скрам это благословение и проклятие в одном флаконе, дар небес, который мы не заслужили, и наказание за грехи, которые мы не совершали. Скрам проник в самое сердце нашей индустрии, и теперь медленно убивает ее изнутри. Возникает один вопрос.

Одной из прикладных реализаций чистой архитектуры является гексагональная архитектура — подход, явно выделяющей слои, адаптеры и прочее. Данный подход заслуженно сыскал любовь среди разработчиков на Go — он не требует сложных абстракций или зубодробительных паттернов, а также почти ни в чем не противоречит сложной идиоматике языка — так называемому Go way.

Но есть проблема, которую я часто вижу во многих командах, адаптирующих гексагоны, и с которой я сам столкнулся и успешно решил — реализация транзакций базы данных в рамках DDD и пресловутого гексагона. Что у меня вышло я и расскажу в этой заметке.

Такой подход я активно использую при разработке сервисов со сложным многоступенчатым поведением, где до сих пор он показал себя довольно неплохо (хотя и не без проблем).

КПДВ отсюда

Чего я не знал тогда, так это почему программисты делают это. Было очевидно, что они делают это; но почему индустрия разработки программного обеспечения создает так много дикого, сложного и нечитаемого кода? Почему это продолжается даже после того, как, казалось бы, разработчики должны были извлечь урок из первого негативного опыта? Что заставило программистов не просто написать плохой код, а продолжать делать это снова и снова?

1. Скачать и установить VMware Workstation 8 (я использовал Workstation 8.0.4, но с другими тоже должно работать)