Ведь это же самые что ни на есть бизнес-правила. Например: менеджер по продажам отправляет на расчет конфигурацию оборудования. Менеджер финансового отдела её считает. Директор финансового отдела - утверждает расчет. И никто, кроме фин.дира не может утвердить ещё не утвержденный расчет.
Это же всё задачи авторизации, понять, что тот или иной актор имеет те или иные права. И все эти акторы и их права - взяты из бизнеса. Почему тогда это не задача предметной области.🤷♂
А давай зайдём с другой стороны - почему возникает такой вопрос? Ну мол не все ли равно. Скажем "фин деректор утверждает отчёт" - значит ли это что логике утверждения там и ревью есть дело что это именно фин директор и в целом кто определяет эти правила. Правила кому что можно скорее всего будут меняться независимо от "как что происходит". По этой причине мы хотим разделить эти вещи. + Ещё важный фактор - насколько логика поддается обобщению. Простой rbac как ты описал отлично поддается и в целом можно взять готовый продукт для управления доступами и т.д. это будет свой контекст который относится к generic домену и разница лишь в том что для generic ты будешь брать from the shelf software по возможности.
Вы верно пишете, про responsibility segregation. Почему сам агрегат не должен это проверять-то? Это же доменное правило.
Обсуждают сегодня