Домашняя работа по первой неделе (2-3 урок) #1
Conversation
alexey-agafonov
added
the
documentation
There was a problem hiding this comment.
Привет!
Что бы было проще с неймингом и что бы закрепить различие названий бизнес команд, я описывал что такое бизнес событие в другой домашке, продублирую тут, возможно будет полезно для понимания концепции:
Любое событие - результат выполненного действия. У нас в курсе есть два действия: бизнес логика (команда из ES) и изменение агрегата/ресурса (из этого CUD событие выходит, мол сделали create/update/delete для агрегата/ресурса). Нас интересует бизнес логика в виде команды.
Нам важно описать поведение системы с точки зрения различных пользователей. т.е. описать команды которые могут совершаться пользователями, вместо того, что бы описать, что программа/система должна сделать с технической части. Т.е. мы описываем ожидаемое действие, вместо описания того, как это действие будет выполнено.
Пример тут: закрытие двери. Мы не пишем "приложить силу для разгона двери к стороне противоположной той, что от петель, до состояния когда угол между дверью и стеной составит нуль градусов". Вместо этого, мы пишем "закрыть дверь". С точки зрения software систем, "Create accounting payment log" это такое же описание как и "приложить силу ..."
Если взять пример в виде обычной бутылки для воды (я на разборе его приводил), бизнес логикой будет команда на открытие бутылки, так как мы, как пользователь открываем бутылку. Тут возникает специфика разработки, так как мыслим тем, какую последовательность действия совершить надо, а не то, что делается над нашей системой. В примере с бутылкой, бизнес команда "открыть бутылку" в технической реализации превращается в набор шагов: взять крышку, прокрутить крышку против часовой, убрать крышку. Поэтому важно ловить себя на использовании терминов в духе "провернуть крышку против часовой" и использовать термины которые совершает пользователь над системой "открыть бутылку".
Возвращаясь к бизнес событию, в системе с бутылкой это будет "бутылка открыта", но никак не "крышка взята"/"крышка провернута против часовой стрелки"/"крышка убрана".
Общие вещи, на которые я бы посоветовал обратить внимание:
Цена задачи в таск трекере
На разборе дз обсуждали, почему цена за задачу - это часть контекста связанного с аккаунтингом.
ТЛДР звучит так: с точки зрения поведения системы (не технической имплементации), цена задачи нужна только когда мы говорим о работе с деньгами, следовательно, без этой цены аккаунтинг работать не будет. Если цена будет в таск трекере - нам придется из контекста в контекст ходить и часть логики из аккаунтинга (как цены задаются) переводить в контекст таск трекера, чему там не место. Следовательно мы увеличиваем coupling, что в будущем приводит к распределенным монолитам ибо связанность стоит держать минимальную между сервисам (поэтому мы данные стримим), при этом, связанность тут в том, что сервис таск трекера знает как задать цену, которую необходимо нам использовать в аккаунтинге. А аккаунтинг не может работать, если сломается таск трекер.
При этом, в других условиях и требованиях, возможно цена была бы в другом месте, но мы рассматриваем явно описанную систему.
Реализация биллинга/аккаунтинга
Посмотри пожалуйста факультатив по реализации аккаунтинга, там было показанно, как уйти от аудит лога в сторону транзакционного поведения. Это позволит упростить логику и гарантировать консистентность баланса и лога
Технические шаги вместо бизнесовых комманд
Довольно распространненый случай, вместо поведения системы с точки зрения процессов бизнеса (что система делает), описывать технические шаги (как система что-то делает). Об этом выше в примере с открытием бутылки. Примеры которые я нашел в ПР-е
Это два технических шага одной бизнесовой команды (регистрация задачи в таск трекере)
Аналогично, два технических шага одной команды
Аналогично
Все остальное выглядит хорошо 👍
| * task assigned; | ||
| * all tasks assigned; | ||
| * task completed; | ||
| * task status changed; |
There was a problem hiding this comment.
Это техническое описание того, как была реализована команда (т.е. описал как произойдет что-то, а не что произойдет)
|
|
||
| # CUD-события | ||
| * create, update, delete users; | ||
| * task added (для аккаунтинга нужно посчитать стоимость таски). |
There was a problem hiding this comment.
тут тогда надо писать task created, мы же описываем что с агрегатом произошло
@davydovanton @f213