На нулевой неделе спроектировал следующую систему:
Использовал подходы полученные на курсе Анализ Систем: https://github.com/nomba/ates
После изучения уроков первой недели и прочтения чатика внёс ряд изменений. Вообщем стал воспринимать систему больше как учебную, а не реальную:
- Сервис Authn/Authz становится не просто техническим решением, а отдельным элементом системы с отвественностью за создание и изменения пользователь, которым ранее занимался Таск-трекер. С помощью него мы также осуществляем аутентификацию, так как нужен SSO.
- Реализации UI не требуется, поэтому вместо Layered Monolith использую только Web API
Диаграмма поведения остается с нулевой недели:
В модель данных вношу:
- "Хозяином" попугов является сервис Authn/Authz
- Выделяю роль попуга в отлельный квадратик, так как она упоминаются в требованиях, а значит на нее нужно обратить внимание.
- Добавляю стриминг аккаунта попуга в аналитику
Спорный момент - это определение цены таска, кому делигировать ответсвенность за просчитывание награды за выполнение таска? Я решил привязаться к текущим требованиям, из которых, насколько я понял, зарплата попуга зависит только от количества закрытых задач, а не от её цены:
формула, которая говорит сколько начислить денег сотруднику для выполненой задачи —
rand(20..40)$
Соотвественно цена таска для попуга не имеет значение и в контексте таск трекер не имеет смысла. Плюс требование, намекает на то что цена прилитает из другого сервиса:
цены на задачу определяется единоразово, в момент появления в системе (можно с минимальной задержкой)
Всё же, если глянуть на проблему с реальной стороны, то такск-трекер - это штука, которая должна повысить мотивацию сотрудников, и его существование в отрыве от награды за таск вызывает сомнения. Текущий алгоритм поощрения - абсурден, если бизнес начнет развивать систему и пробывать другие гипотезы, то явно возникнет желание управлять наградами в контексте трекера. Поэтому если помыслить стратегически, то я бы ввел условные единицы (point) за таски, а в аккаунтинге уже конвертировал их бы в деньги, таким образом оставив трекеру возможность "самостоятельной" проверки гипотез на основе награды, а аккаунтинг при этом занимался реально только слежкой за балансом и выплатами.
Но чтобы не усложнять, будем реализовывать текущие требования. Итоговая система выглядит так:
Данное событие пересекается со стриминг событием, я решил выделить отдельное бизнесовое, т.к. при создании таска необходимо списать деньги с попуга, это влияет на поведение системы. Можно было сделать отдельное событие "Таск назначен" и вызывать его и при создании и переназначении, но тогда не выполнится требование (инвариант системы):
f) Создать задачу не заасайненую на пользователя нельзя. Т.е. любая задача должна иметь попуга, который ее делает
- ID таска
- Название
- Попуг ID, на корого назначен
- Время создания
- ID таска
- Название таска
- Новый Попуг ID
- Предыдущий Попуг ID
- Время переназначения
- ID таска
- Название таска
- Попуг ID
- Время выполнения
- ID таска
- Название таска
- Описание таска
- ID назначенного попуга
- Время создания
- Время выполнение
- ID таска
- Цена таска
- Время, когда цена определена
- ID попуга
- Имя попуга
- Роль попуга
- Время регистрации
- ID счета
- ID попуга
- Баланс