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

Иногда приходится интегрироваться с системами, которые работают в асинхронном режиме, но при этом выставляют 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% проектов действительно успешны — укладываются в сроки, бюджеты и оправдывают ожидания.

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

Итак, мы приняли решение использовать подход Domain Driven Design для реализации нашего приложения. Мы собрали экспертов доменной области. Провели несколько сессий Event Storming. Выделили основные события, агрегаты, нарисовали карты контекстов и приступили к реализации.