Ребят, а чем я рискую если обычно делаю так 1) слой

инфраструктуры
2) сервисный слой
3) domain
- usecases
- domain entities
4) слой данных

Где слой сервисов - это что-то вроде фасада для usecase. Как пример это регастрация пользователя через кафку, http, консоль. Сервисный слой предоставляет удобный интерфейс для эндпоинтов приложения, а сам использует один и тот же RegistrateUserUseCase.

И второй вопрос, можно ли вызывать несколько usecase друг за другом, допустим паттерн pipeline?

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

рискуешь сосредоточиться на изоляции слоёв, вместо изоляции модулей

По итогу слоистая херня получится

Блинный торт

Mikhail Kobychev
А если упарываться в горизонтальное деление то мож...

а для чего ты вообще на слои делишь?

Наверное, чтобы каждый слой имел свою конкретную функциональную ответственность

а что это даёт на практике?

Это дает выделить домен, сделать из него конечный автомат(в широком смысле), и дергать API вашей доменки(один из UseCase) из разных точек входа в приложение (админка/пользовательский экшн/консьюмер/метод старого API), и все эти точки входа могут дергать один единственный UseCase. Дальше уже вариативность и вкусовщина. UseCase может сам сверху работать с сущностью по анемичной модели, и следить за инвариантами системы, либо может делегировать это самой сущности, сделав ее "богатой", и заниматься только проверкой консистентности данных в приложении, для определения можно ли совершать эту команду, или нет с точки зрения бизнеса. В итоге получаем четкие границы слоев, каждый из которых имеет свои ответственности, и позволяет переиспользовать код, который находится на более низких уровнях(более близкими к ядру приложения) Можно погуглить картинку "Чистая архитектура", станет чуть понятнее

слои про дата флоу, про функциональную ответственность модули

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

1 и 3 пункты по сути про реюз кода я вижу проблему в том, что идея разделения на слои никак не ограничивает этот реюз Получается, что каждый юзкейс может зависеть от любого количества объектов из слоя домена и это выглядит как шаред стейт

это уже про контексты