ну там просто описалово хорошее, расширяющее представление янга

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

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

к-ую вот недавно публиковал, про цену переезда на микросервисы

Расширение смыслов это не всегда хорошо

Вопрос по дизайну HTTP API:
Есть условное расписание и пользователь меняет его. Мне нужен метод API для того, чтобы проверить валидено ли его изменение. Это сложный алгоритм, который будет только на сервере, чтобы не дублировать его еще на фронте.
Так вот получается, что мне нужно что-то вроде GET запроса с телом, где будет структурки, которые должны будут измениться. Но вроде как в GET не принято юзать тело. Тогда лучше юзать POST? Но я вроде ничего не меняю, а POST больше ассоциируется с изменениями.
Сразу менять я не могу, ибо мне нужно, чтобы пользователь сначала “подвигал“ расписание, те это несколько этапов изменений, где бы ему показывались возможные ошибки, а далее уже сохранение

А к структуруе по какому нибудь униальному полю обратиться можно?

Можно,
но я отправляю новые структуры или измененные соответсвенно с новыми значениями.

Если они измененны то разве не требуют еще и сохранения состояния и если новые тоже , можно Post /Patch юзать

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

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

Понял, спасибо. Просто ранее в пост такое не пихал)

Добрый день!

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

Абстрактный пример. Есть проекты с полями:

- id
- название
- дата начала
- дата завершения
- статус
- тип проекта

...и несколько типов проектов:

проекты по доставке оборудования:
- логист
- маршрут доставки
- стоимость доставки

проекты по написанию технической документации:
- авторы
- куратор
- описываемый объект

То есть у каждого типа есть специфические поля/сущности/функционал.

Наследовать сущности мне кажется не очень хорошим решением, что-то вроде:

abstract class Project;
final class DeliveryProject extends Project;
final class DocumentationProject extends Project;

Придумал вот такой вариант: в домене есть сущность "Проект" (общие поля) и есть отдельные сущности под каждый тип проекта (только специфический поля типа проекта, но в качестве ID используется ID проекта). Создание проекта происходит всегда через доменный сервис, который одновременно создаёт две сущности.

Минус тут в том, что нарушается правило изменения только одного агрегата.

Наверняка есть лучше вариант проектирования таких вещей... подскажите, куда смотреть, что почитать?

Лучше избегать общих названий - всегда "общие вещи" можно вынести в свою сущность типа project details и для каждого типа делать свое

Open/close, srp, вот это вот все

Да, вынести можно, но тогда мы получим тольок для каждого типа проекта отдельные сущности и потеряем само понятие "Проект", а ведь оно важно.

На счёт "изменения только одного агрегата" - нет таких правил. Более чем нормально что в рамках одной бизнес операции происходит несколько логических транзакций

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

Части функционала работает с общим понятием "Проекта", не понятно как быть, если у меня такой сущности не будет.

А почему айдишки недостаточно