KIT

Definition of Ready: как не брать в работу «сырые» задачи

Сколько раз мы брали задачу в работу, а в середине ее разработки выясняли, что некоторая часть требований не описана, а API, с которым будем интегрироваться в процессе, еще не готов?

В итоге половина запланированного времени уходит на уточнения, описания и переделку того, что уже сделали (привет, миграции Liquibase!).

В таких случаях стоит внедрить в процессы команды практику Definition if Ready (DoR).


📉 Почему «начнём разбираться в процессе» — это налог на команду

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

⏱️ Постоянные уточнения вместо разработки.
⏱️ Частое переключение фокуса между задачей и согласованием.
⏱️ Увеличение числа переделок.
⏱️ Блокеры, которые можно было бы снять заранее.

В результате значительная часть времени работы команды уходит на выяснение требований и постоянные переделки.

Definition of Ready — это способ уменьшить этот налог.


🔄 DoR: что должно быть у задачи, прежде чем отдать ее в разработку

Definition of Ready — это четкий набор критериев, согласованный в команде, которым должна соответствовать задача, прежде чем ее возьмут в разработку.

DoR отвечает на вопрос: «Готовы ли мы начать работу над задачей прямо сейчас, не отвлекаясь на бесконечные уточнения?» Это фильтр на входе, который защищает команду от сырых и непроработанных задач.

Как и Definition of Done, DoR не должен содержать чек-лист из 50 пунктов. Это несколько, обычно 5–7 критериев, которые защищают от ключевых рисков. Вот некоторые универсальные критерии:

✅ Четкое описание — задача описана понятно, есть цель (в том числе и бизнес-цель), контекст и ожидаемый результат.

✅ Есть критерии приемки — четкие, проверяемые условия, по которым понятно, что задача сделана.

✅ Дизайн/макеты/API спецификация готовы — все, что нужно, доступно и согласовано.

✅ Технические зависимости закрыты: контракты API со смежными командами согласованы, доступы получены, архитектурное решение (если задача крупная) утверждено.

✅ Задача декомпозирована — размер задачи позволяет закрыть ее в рамках одной итерации.

Если хотя бы один из критериев DoR не выполнен, задача не готова к передаче в разработку. Она готова к обсуждению, спецификации и проектированию, но не к разработке.


📝 Важное уточнение: DoR — это ответственность команды, не только бизнеса

Частая ошибка — относиться к DoR как к требованию к бизнесу. Это не передача задачи от бизнеса в разработку.

Это командная работа — подготовить задачу так, чтобы она удовлетворяла критериям DoR. Требуется, чтобы бизнес описал потребность, архитекторы приняли решения о том, какие системы менять, а команда разработки заполнила детали реализации.


🛡 Как сказать «нет» задаче на планировании без конфликта

Здесь можно воспользоваться рекомендациями из поста про то, [как выдержать давление при оценках]. DoR — это легальный способ перевести эмоциональный разговор в процессный:

🔄 Смена фрейма — задача важная, но сейчас не закрыты все DoR-критерии, давайте вернем ее в бэклог и доработаем, чтобы защитить качество и сроки разработки.

🗣 «Да, и…» — да, мы готовы взять задачу в разработку, но для этого нам нужны макеты до среды. Если дизайн будет готов, то задача пойдет в работу на следующей неделе.

🎯 Вопрос-возврат — нам важнее закрыть бэклог на спринт или взять в работу задачу, которую реально доведем до продакшена?


💡 Вместо вывода

Definition of Ready — это не бюрократия, не способ загрузить бизнес бумажной и формальной работой. Это инвестиция в предсказуемость.

Команда, которая использует DoR:

✅ Меньше простаивает в ожидании ответов;
✅ Реже переделывает уже написанное;
✅ Точнее попадает в оценки;
✅ Сохраняет фокус и мотивацию
.
Начните с малого: выберите 3–4 самых критичных пункта DoR и попробуйте применять их.

#DoR #agile #scrum #processes #management #TeamLead #team

Всем привет!

Подготавливая следующую версию «Гиря – Русский мах», пришел в восторг от того, что изначально использование подходов из DDD для моделирования моей доменной области дало хорошее преимущество при использовании агентов для программирования.

Именно та часть приложения, которую я тщательно моделировал, в том числе с использованием Event Storming, претерпевает минимальные изменения. Да и расширение функций модели потребовало совсем мало времени и трудозатрат.

Для доменной модели использовал подход State Driven Domain Model. Очень хорошо подошел данный подход для реализации переходов между состояниями. Но нашел также и неприятный минус — если нужно добавить события, то столкнетесь с неразрешимыми противоречиями :(. Чуть позже напишу об этом.

Какую мысль хочу донести - использование DDD позволит писать код с помощью ИИ быстрее и качественнее.

#AI #DDD #kettlebells

Как поживает приложение:

- За полтора месяца - почти 600 установок и около 62000 просмотров страницы.
- Активных пользователей в день - около 50 человек
- Из них до конца тренировки доходит около 10!

Никакого продвижения нигде не использовал. Только органический трафик. Сам RuStore отлично продвигает новые приложения. Для сравнения в Google Play на той же дистанции показал мое приложение(не это, совсем другое) всего около 5 раз :)

Есть планы на расширение функционала!

Всем привет!

Куда я пропал?

Был в отпуске, да и на рабочем проекте сейчас самый завал, поэтому писать посты не хватает времени!

Хочу немного поэкпериментировать с форматом постов.
Будут как короткие посты, так и длинные.
Возможно, попробую формат видео - коротких и не очень.

Если вам зайдет какой-то из форматов ставьте 🔥 или пишите в комментарии.

Как у вас проходит лето?

Когда использовать Transactional Script

Transactional Script — идеальный выбор в следующих ситуациях:

✔ Простые CRUD-операции, где логика — это валидация и сохранение.

✔ Операции с четкой последовательностью действий, не требующие сложных инвариантов.

✔ Отчеты и аналитика — собрать данные и выдать результат.

✔ В рамках DDD — для простых ограниченных контекстов (Bounded Contexts), где сложность домена простая.

✔ На начальных этапах проекта, когда еще не разобрались в доменной области.

В контексте DDD важно понимать: использование Transactional Script — это нормально.

DDD не требует повсеместного применения Domain Model. Он требует осознанного выбора инструмента под задачу.

Если контекст прост — используйте простой инструмент.

#DDD #SoftwareArchitecture #designpatterns #BoundedContext

Ошибки при реализации Transactional Script

Очень частая ошибка — пытаться сделать красиво. Вспоминаем все практики из Clean Code и начинаем разбивать логику, чтобы код соответствовал всем принципам ООП — SOLID, DRY, SLAP и т. п. В результате бизнес-логика начинает размазываться по куче классов, и нам придется потратить много времени, чтобы разобраться.

Вот один из таких примеров:

public OrderDto createOrder(CreateOrderRequest request) {
Order order = orderFactory.create(request); // <- Что делает фабрика? Непонятно.
orderRepository.save(order);
return orderAssembler.toDto(order); // <- А здесь внезапно считается цена?
}
Такой код выглядит чистым, но скрывает и размазывает бизнес-логику по куче классов.

Еще один пример, который часто встречается во множестве проектов:

public OrderDto createOrder(CreateOrderRequest request) {
// 1. Валидация входных данных
validateRequest(request);

// 2. Создание заказа
// ОШИБКА: Бизнес-логика скрыта! Мы не видим, как считается цена,
// применяется ли скидка и проверяются ли остатки.
Order order = orderFactory.buildOrderFromRequests(request);

// 3. Сохранение
orderRepository.save(order);

// 4. Отправка события
eventPublisher.publish(new OrderCreatedEvent(order.getId()));

// 5. Возврат DTO
return toDto(order);
}

Здесь важная бизнес-логика скрыта в фабрике, которая создает заказ. Мы не видим, как считается цена, применяется ли скидка и проверяются ли остатки.

Transactional Script — это не про «чистоту», а про прозрачность бизнес-процесса.

Transactional Script: основа бизнес-логики

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

Этот паттерн был впервые формально описан Мартином Фаулером в его книге Patterns of Enterprise Application Architecture (2002), хотя самим подходом разработчики пользуются столько же, сколько существует программирование. Фаулер каталогизировал его как один из основных способов организации логики в корпоративных приложениях.

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

Давайте разберем все по порядку.


Как правильно писать transactional script

Давайте посмотрим, как организовать Transactional Script на «классическом» примере оформления заказа в интернет-магазине:

public class OrderService {
public OrderDto createOrder(CreateOrderRequest request) {
// 1. Валидация входных данных
validateRequest(request);

// 2. Создание заказа
Order order = new Order();
order.setCustomerId(request.getCustomerId());
order.setStatus(OrderStatus.CREATED);
order.setItems(request.getItems());

// 3. Расчёт итоговой цены
BigDecimal total = calculateTotal(request.getItems());

// 4. Применение скидки (если есть)
if (request.hasPromoCode()) {
PromoCode promo = promoRepository.findByCode(request.getPromoCode());
if (promo != null && promo.isValidFor(total)) {
total = total.subtract(promo.getDiscountAmount());
}
}

// 4.1. Установка итоговой цены
order.setTotal(total);

// 5. Сохранение
orderRepository.(order);save

// 6. Отправка события
eventPublisher.publish(new OrderCreatedEvent(order.getId()));

// 7. Возврат DTO
return toDto(order);
}
}

Ключевой принцип:

Вся бизнес-логика должна быть явно видна в одной функции — «скрипте» транзакции.
Можно выносить:
- валидацию,
- маппинг в DTO,
- обработку ошибок,
- технические детали (сохранение, публикация событий).

Но не стоит прятать саму суть операции — расчёт цены или применение скидки, в другие классы или методы без явной причины. Иначе логика «размазывается» и понять, что происходит становится сложно.

Saga vs Process Manager: это одно и то же?

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

Один из источников путаницы - смешивание Saga и Process Manager.
Давайте разберемся чем они концептуально отличаются.


Что такое Saga в классическом понимании

Saga - паттерн управления согласованностью данными и транзакциями в распределенных системах.

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


Что такое Process Manager

Process Manager - это паттерн проектирования, который позволяет управлять сложными процессами, выступая в качестве центрального координатора/оркестратора.

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


Ключевые различия паттернов

Между этими паттернами есть фундаментальные различия.

Фокус

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

- Process Manager - управление workflow (потоком) и логикой процесса. Он решает проблему консистентности.

Состояние

- Saga обычно реализуется без сохранения состояния. Решения принимаются на основе входящих событий.

- Process Manager обязательно хранит состояние процесса. Часто реализуется как State Machine с сохранением состояния в хранилище.

Тип логики

- Saga - это последовательность локальных транзакций с механизмом отката. Это продвинутый "транзакционный скрипт" для распределённой среды.

- Process Manager - это движок workflow или State Machine. Управляет сложной логикой потока: условия (if/else), параллельные ветки (fork/join), циклы, ожидание внешних событий и триггеров.

Компенсации как обязательный элемент

- В Saga компенсации - неотъемлемая часть паттерна. Его центральный механизм.

- В Process Manager - компенсаций может и не быть. Процесс может завершиться каким-либо терминальным статусом, указывающим на ошибку - failed/cancelled.

Отношение между ними

- Saga - это инструмент согласованности данных и компенсаций.

- Process Manager — координатор/орchestrator, который может использовать Saga как шаги внутри более сложного процесса, для поддержки согласованность данных.


Заключение

Не путайте инструменты:
- Нужна согласованность в распределённой транзакции - используйте Saga.
- Нужен сложный, долгоживущий бизнес-процесс с состояниями, ветвлениями и правилами - Process Manager .

Часто в реальных проектах они комбинируются - и это нормально.

Главное - понимать границы ответственности.

#saga #processes #systemdesign #SoftwareArchitecture

Реализация бизнес-логики: от стикеров Event Storming к реальному коду

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

Теперь перед нами возникают вопросы:

➤ Как реализовать код и логику наших моделей.

➤ Какие есть варианты и подходы к имплементации бизнес-логики?

➤ Всегда ли надо использовать паттерн Domain Model?

Давайте разберемся...


Какие паттерны существуют для реализации бизнес-логики

В своей книге "Patterns of Enterprise Application Architecture" Мартин Фаулер выделил несколько подходов к организации бизнес-логики. Со временем наибольшую популярность среди разработчиков и архитекторов приобрели следующие паттерны:

✦ Transactional Script

✦ Active Record

✦ Domain Model

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

Рассмотрим более подробно, что из себя представляет каждый из них.


Transactional Script

Наиболее распространенный паттерн для реализации организации бизнес-логики. Большинство разработчиков так или иначе использовали его.

Суть паттерна:
Каждый use-case/пользовательская операция — это одна процедура (метод), в котором последовательно выполняются основные действия, такие как валидация данных, загрузка и сохранение, вызов внешних систем и бизнес-правила (if-ы или более сложная логика, реализованная, например, через стратегию).

Плюсы:

✚ Просто понять и написать.

✚ Минимум абстракций.

✚ Легко отлаживать

Минусы:

━ При росте логики превращается в огромные методы на 300–500 строк.

━ Логика может дублироваться между похожими сценариями.

━ Трудно тестировать — часто приходится использовать только интеграционные тесты вместо unit-тестирования.

━ Анемичная модель (модель — просто DTO / запись из БД).


Active Record

Этот паттерн обрел популярность с появлением ORM-фреймворков.

Суть паттерна:
Каждый объект объединяет в себе данные и поведение. Каждая сущность знает, как отображать содержимое хранилища на внутреннюю структуру. Часто поведение таких объектов ограничивают проверкой целостности и другими небольшими бизнес-правилами вроде валидации.

Плюсы:

✚ Быстрый старт разработки.

✚ Меньше boilerplate-кода по сравнению с Transactional Script.

✚ Логика находится близко к данным.

Минусы:

━ Смешивание отвественности — Domain-логика + логика сохранения/загрузки.

━ Трудно тестировать без хранилища данных.

━ Легко нарушить инварианты.

━ Сложно эволюционирует, так как завязана на данные.


Domain Model

Сердце DDD. Бизнес-логика инкапсулируется внутри объектов-моделей, которые отражают понятия предметной области. Сущности, объекты-значения — все работает совместно, чтобы отразить суть бизнеса в коде.

Суть паттерна:
Абстрактная модель, которую обычно представляют в виде графа взаимосвязанных объектов. Данные и поведение неразрывно связаны, при изменении данных вызывается проверка бизнес-инвариантов, чтобы обеспечить целостность логики.

Плюсы:

✚ Высокая выразительность модели.

✚ Хорошая поддержка изменений.

✚ Защита бизнес-правил.

Минусы:

━ Высокий порог входа.

━ Требует высоких расходов на проектирование.

━ Избыточна для простых задач.


Какой паттерн и когда выбрать

Здесь нет серебряной пули. Ответ зависит от сложности домена и субдомена, с которым работаем в данный момент.

✔ Transactional Script
→ простые домены, CRUD, интеграционные сервисы.

✔ Active Record
→ умеренная сложность, быстрый time-to-market, стандартные правила.

✔ Domain Model
→ сложный бизнес, долгоживущая система, активная эволюция требований.


Важно понимать:

- DDD не обязывает вас всегда использовать Domain Model.

- Необходимо осознанно выбирать паттерн реализации модели, чтобы он соответствовал сложности домена и целям бизнеса.

Привет всем!