Отсутствие зависимости от логики представления

Когда бизнес-логика находится в собственном классе, вы можете вызывать ее откуда угодно. Из обычных представлений Django, конечных точек JSON, команд управления, задач RQ, административной панели Django и т.д. Бизнес-логика больше не привязана к представлениям или моделям.

Легкое тестирование и моканье

Так, как сервисные объекты - это просто объекты, вы легко можете их вызывать из тестов для проверки поведения. Точно так же, если вы тестируете свое представление(view) или конечную точку (endpoint), вы можете легко смоделировать(mock) сервисные объекты.

Проверка входных параметров

Ваш код станет более кратким, так как вам не нужно вручную проверять, является ли параметр допустимым. Если вам нужно знать, почему ваши входные данные не прошли проверку, просто перехватите InvalidInputsError и получите доступ к ошибкам или словарю non_field_errors. А еще лучше вызвать свое исключение из сервисного объекта.

Но толстые модели…

Модели сделали слишком много вещей. Кроме того, было не совсем ясно, к какой модели отнести метод, когда он работает с двумя разными моделями. (Метод create_booking() должен быть у Booking или Customer)?