Вроде у Мартина было, что UseCase - это автоматизация за счет программной системы. Потому в домене это менее ожидаемо увидеть. Хотя! Это по-прежнему ядро системы, просто чуть внешне располагаются от Entities.

Да, немного запутался. У меня просто есть случаии, когда события нужны только верхнему элементу, например при рекурсивном удалении. Из-за этого есть удаление с событием и без события в репе.

спасибо. Да это по фичим или контекстам. Скорее в данном случае это контексты из названий.

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

допустим у меня есть директорри с документами разных видов. Мне надо рукурсивно удалить директорию со всеми вложенными доками и директориями. При этом события мне нужны только от нее и тихое удаление от вложенных.
Так как тут задействовано несколько моделей и репозиториев это все лежит в application  папке. По сути это и есть use case.  Меня смутило только то, что в примерах на github папка usecases или interactors  нажодиться чаще в domain папке...
Мое непонимание от того, что хочется совместить Clean Architecture с DDD, а они немного про разное 🙂

А еще хочу FP на не на fp языке, но пока это совсем туго идет

Если у тебя в одном случае кидается событие, а в другом нет, то это два разных события

У меня событие на удаление поддиректории, но мне оно не нужно при удалении элементов этой директории

Событие либо происходит, либо нет. Нужно оно или не нужно - не эмиттера дело

Наверно проще всего это разрулить самим репозиторием и работой только в дата слое при рекурсивном удалении.

Пробелема только, что репозиторий для дирректорий и он не должен знать про документы.

Репозиторий не должен кидать такие ивенты. Найди выше по цепочке кто знает что все сделано и вот там кидай ивент

спасибо

Правильно я понимаю, что кидать на EventBus  доменные события ответственность не репозитория, а application слоя?
Сам домен их не может кинуть, так как он не занет сохранилась ли модель в базе или нет.

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

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

Подтверждаю.
Обычно ивенты накапливаются в буфере (например сущность сохраняет эвент в свою внутреннюю очередь) и обрабатываются при комите (все эвенты вычитываются из очереди переданных на сохранение сущностей и распределяются по таргетам). Управление временем исполнения можно организовать как хранение метадаты в эвенте.

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

Я пока с этим разбирался у меня еще вопрос появился...
Нашел у Вернона, что репозиторий используется в доменной модели. Это плохой тон или так делать можно? Если можно, то в каких случаях? Или это лучше делать отдельным юзкейсом или сервисом?
Если надо посчитать что-то по сущностям, например общий объем занимаемого места дирректории и ее содержимого, то это примерно так делается: Калькулятор является доменной моделью, которая делает выборку и содержит состояние результата?

https://github.com/VaughnVernon/IDDD_Samples/blob/05d95572f2ad6b85357b216d7d617b27359a360d/iddd_agilepm/src/main/java/com/saasovation/agilepm/domain/model/product/backlogitem/BusinessPriorityCalculator.java#L24

думаю стоит начать с того что бы сформулировать "что такое доменная модель". А то людям в головы всякое MVC насрало.

интерфейс репозитория в целом определяется на уровне домена. Потому юзать интерфейс внутри доменного слоя не есть проблема