Если от статуса ничего особо не зависит - нахер его вводить непонятно.

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

как то звучит как оверинжениринг)) может я не понял посыла

Можем разобрать тут пример если у тебя есть под рукой

У меня под рукой есть сущность с 9-ю статусами и эти статусы оч много связанности вызывают. Эту сущность можно в моем случае разбить на 4 штуки и вся логика упрощается

Опять же проще на примере, ток мне лень его придумывать. Если интересно опишите свой кейс (ток чёт интереснее Todo in progress done)

На руках данные буду иметь во вторник.
Благодарю за помощь.
Подумаю насчет разбиения и подумаю не является ли это todo in progress done.

Ну те же транзакции в платежной системе - создана, клиент выбрал метод оплаты, клиент на этапе 3d secure, ошибка, успешное списание, возврат средств

как это разделить?

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

В итоге можно сделать 2 объекта каждый из которых поддерживает свой сэт операций. Надо ли так делать в этом конкретном случае - скорее всего нет ибо флоу достаточно простой. Но иногда полезно особенно когда разные зависимости по данным

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

понял

обычно просто во всяких примерах по DDD/агрегатах - статусы как раз одни из самых популярных примеров (типа как мы будем гарантировать инвариант что этот статус не может быть установлен тогда то)

И обычно все это делается в одном объекте, и как мне кажется, в таких случаях все там можно и оставить

ну в нулевых годах много чего по другому делали. если ты делаешь систему с которой работает 100 пользователей (автоматизация бизнес процессов) или b2c на лям людей то технические подходы будут отличаться а DDD останется. более того с популяризацией всяких микросервисов и распредеенных систем (лямбды всякие) польза от анализа процессов только повышается

Тут для начала нужно договориться о том, что половина этих статусов в транзакции не нужна

Т.е можно, например, инициировать транзакцию только в случае успешной авторизации карты

Тогда всякий выбор пеймент метода, 3д секьюр и прочие просто пройдут мимо системы

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

Но это просто пример, всё от системы и требований зависит, конечно же

я тут имел ввиду что мы сами и являемся платежной системой)

а не используем тот же страйп

ну я не шарю в этом домене а потому мне сложно тут предлагать чего. Смысл в том что бы постараться явно выделить этапы жизненного цикла и что бы не получалось так что у тебя есть сущность со статусом но разные операции делают проверки на статус + им нужны разные данные (уменьшить пересечение транзакций). Так же важно что бы сущность по итогу из-за этих статусов не выходила "общей" для нескольких bounded context.

Но в целом если проект не оч большой и не приходится потом писать документацию че какой статус значит и какие там могут быть правила ибо черт ногу сломит то проблемы нет и делаем попроще

просто если у человека такой вопрос возникает (че делать со статусами) то наверное там чет более интересное. Я например парюсь только в ситуации когда статусы мешают мне разбить систему на модули нормально