Ну смотри, в таксономиях SOA, а их несколько, было примерно следующее:
- Process services
- Business services
- Entity services
- Utility services

Иными словами, должно быть нечто (сервисы), что предназначено изначально для поставки бизнес-ценности.

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

типов сервисов как грязи

Тип разность логику так, что бы она могла отдельно сосуществовать с другими кусочками?

В каких то мальких штуках я пишу все в “контроллерах”, те не разношу логику, и можно сказать, что это соблюдает SRP, ведь я никогда их не трогаю, они write only

https://enterprisecraftsmanship.com/posts/domain-vs-application-services/#:~:text=The%20main%20difference%20between%20them,whereas%20application%20services%20don't.&text=And%20application%20services%20orchestrate%20those,by%20entities%20and%20value%20objects.

норм статейка, разжовано прям

Благодарю , снова сиШарп, я не понял в какой момент все доки стали с сШарпом

из этого чата у меня только то и делают что ссылки в reading list летят

Чтобы когда тебе нужно было что-то добавить или изменить - это было в рамках одного модуля. Ну как объясняют про UI обычно. Типо есть функция подсчета мороженного на складе. Кто то захочет узнать это через http api, кто-то хочет подписаться на очередь, кто то через другой сервис (телега, например).

Поэтому функции, которые слушают разные UI будут разные. Если у нас меняется http api, нам не нужно менять функцию подсчета мороженного

Да, это я понимаю, но все равно огромное Спасибо

просто подпишись на норм блоги и читай их ингогда)

“Ну то есть у нас приложение, которое берет и формирует pdf карточки , ну или не pdf, не важно , отдача pdfКи стримом = application layer, а конвертация из html в pdf = domain?”

Не важно, что где. Суть в том, что есть отдельная штука, которая формирует из html в pdf. (не понятно откуда html и что это за html) Есть отдельный эндпоинт, которые отдает сгенерированный pdf по http. Ты можешь потом добавить эндпоинт, который бы отдавал этот же pdf через телегу

Нужно ли тут вообще что-то называть domain layer или app layer. Назови одно pdf-html конвертором, другое http эндпоинтом. Те то, чем они являются, а не абстрактными domain или app

😆 У меня просто немного жопку припекает, потому как в java принято плодить кучу ненужного boilerplate с кучей ненужных папочек

истину глаголит молодой человек 👆

даже в чистом коде есть правило для этого

Все понял, спасибо большое

Добрый день!

У сущности есть статус. В зависимости от статуса с ней очень по разному нужно работать. Сделать разные агрегаты под каждый статус - это норм?