Андрей Казаков

Довольно часто возникают такие ситуации:

Иногда приходится интегрироваться с системами, которые работают в асинхронном режиме, но при этом выставляют API с синхронными вызовами.

В предыдущих постах мы разобрали подходы к организации бизнес-логики — Transactional Script, Active Record. Теперь начнем движение в сторону полноценной Domain Model. Но сначала хочется подробнее остановиться на одном из фундаментальных строительных блоков доменной модели — Value Object. Этот паттерн прост по своей сути, но вместе с тем очень часто…

Как часто вы сталкиваетесь с неприятным кейсом - запускаем миграцию liquibase на стенде, а она падает с ошибкой или данные становятся неконсистентны? При этом на машине разработчика все проходит успешно...

В прошлом посте мы разобрали проблему full-scale старта. В этом разберем самый главный вопрос: А с чего же начать?

В прошлом посте мы разобрали классический вариант реализации Active Record. Обсудили, когда стоит переходить от Transactional Script к Active Record.

В прошлом посте мы разбирали Transactional Script - отличный инструмент для старта. Но любой проект развивается. Со временем вы начинаете замечать, что Transactional Script становится сильно усложненным. В них добавляются простые бизнес-инварианты, дополнительные проверки и сами структуры данных становятся довольно сложными.

Ваша система начинает тонуть в хаосе обработки бизнес-процессов, хотя каждый сервис работает отлично "как часы". Простые цепочки вызовов и реакций на события, обработка компенсаций превращается в запутанную, хрупкую и не поддающуюся тестированию архитектуру.

Сегодня мы рассмотрим паттерн Transactional Script — пожалуй, самый популярный и наиболее старый подход к организации бизнес-логики в приложениях. В простых сценариях и контекстах Domain Driven Design именно он будет часто и широко использоваться.

Около 20% проектов терпят провал. От них отказываются или забрасывают еще до старта (по данным Standish Group’s CHAOS study). И только около 30% проектов действительно успешны — укладываются в сроки, бюджеты и оправдывают ожидания.

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