Поэтому я не пытаюсь понять где бизнес-логика, а где нет. Я просто стараюсь делить по ответственности.

реализация чего? сервисов приложения наприимер?

В любом случае декомпозируем и планируем всё сами, командой, разбивая на подзадачи и тп. И иногда не можем понять что куда...

Реализация репозиториев

Вот инфраструктура тоже непонятная имхо херня. Похоже на пакет util из джавы)

хз, я забил на слои и живу счастливо)

Нет, они имеют состояние и поведение)

все имеет состояние и поведение. Это не отличительная характеристика.

А можете показать структуру проекта? Очень интересно

java util нет (если верить ЕГОРУ)

ПС: на java не пишу, но понимаю о чем он говорит в своих спичах

есть оч большая разница.

utils - это про coincidental cohesion. Просто "хуй знает куда положить"
infrastructure - это уже про logical cohesion. "все что про инфраструктуру сваливаем сюда".

И то и то оч низкий кохижен но у infrastructure он чуть выше)

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

Ну я про то, что туда сваливают обычно все то, что не попало в другие места. Пакет/папочка infrastructure - обычно такое себе

Мы туда кладём исключительно реализацию походов во внешние штуки (базы данных, api, кэши и тп), не более

Главное что надо уяснить что "слои не папки".

App
 | - Auth
    | - Credentials
    | - AuthController
    | - CredentialsRepository
    | - HybernateCredentialsRepository
    | - OpenIDClient
 | Shipment
    | - 
 | Platform
    | - пафосное название для "инфраструктуры" которая общая для всех контекстов

В текущем проекте все печально. По сути
controller
service
repostiory
dto
email
security
exception
и тд

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

главное что бы в пределах одного файла* слои не перемешивались а внутри пакета - пжалуста

слои вритуальный концепт который нужен только что бы объяснить людям концепцию разделения ответственности. Не надо переносить ее на структуру проекта. Лучше дробить структуру по фичам. Это позволит лучше понимать у каких фич от каких зависимости и в целом как оно там все устроено. Сваливая все по "слоям" ты теряешь огромное количество полезной информации относительно того как чего в проекте устроено. Ну а "профит" от подобного разделения обычно только в том что "не надо думать куда что положить". Не считаю это плюсом

App
 | - Auth
    | - Credentials
    | - AuthController
    | - CredentialsRepository
    | - HybernateCredentialsRepository
    | - OpenIDClient
 | Shipment
    | - 
 | Platform
    | - пафосное название для "инфраструктуры" которая общая для всех контекстов

Ну вот utils это тоже по сути что-то общее для всех контекстов.

да но platform team звучит лучше чем util team :)