Django - отличный фреймворк, но он, на самом деле, толком не дает, да и не должен давать, ответ на вопрос, каким образом лучше всего хранить вашу бизнес-логику. Хранение бизнес-логики в моделях или views имеет множество недостатков, которые обычно начинают проявляться при росте кодовой базы проекта. Чтобы решить эти проблемы, разработчики часто начинают искать способы выделения бизнес-логики в своем приложении.

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

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

На самом деле, изложенный далее текст относится не только к Django-проектам. Разрабатывая веб-приложения, используя другие инструменты, вроде Flask, люди используют те же концепции веб-разработки, причём часто именно в таком же виде, как они реализованы, в Django - views, request-response объекты, middlewares, модели, формы.

Как обычно обстоят дела в реальных Django-проектах?

Большинство начинающих разработчиков на Django, после прохождения официального туториала, зачастую начинают интересоваться, собственно, а где и как им хранить код? Вариантов много, но типичный Django-разработчик, скорее всего, найдет для себя ответ в знаменитой книге "Two Scopes of Django", заключающийся в следующем принципе: "Fat Models, Utility Modules, Thin Views, Stupid Templates".

Со временем данный подход стал дефолтным в Django-сообществе. И этот подход, несомненно, работает. Какое-то время.

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

Следуя данному принципу, в какой-то момент роста проекта вырисовывается весьма интересная картина.

Эти модели слишком толстые

На самом деле, считаю правило "толстых моделей" корнем всех проблем. Самые простые бизнес-процессы, как правило, взаимодействуют только с одной сущностью. Но с ростом этих сущностей в одном бизнес-процессе у разработчика возникает следующая дилемма: "Ок, я написал огромную простыню кода, которая использует несколько моделей. В какую из моделей мне положить всё это добро?".

В худшем случае разработчик оставит весь код в модели, импортируя модели друг в друга или вынося некоторые куски кода в некие другие модули, затем снова импортируя их эти же в модели. Добро пожаловать в кольцевые импорты! В вырожденных случаях разработчик может просто начать складировать код всех моделей и их логики в один файл, получая на выходе один models.py на 1000+ строк кода.

Но чаще всего бизнес-логика начинает плавно перетекать во views.

Кажется, наши тонкие views становятся не такими уж и тонкими

Авторы "Two Scopes of Django" сами же пишут, что хранение логики во views - плохая идея, и вводят в своей книге главу "Trimming Models", в рамках которой поясняют, что при росте модели логику стоит выносить в слой, который они называют "Utility Modules".

Однако, реальность довольна сурова. Бизнес-логика перетекает во views бесконтрольно, потому что никто точно не может сказать, когда наша thin view стала не такой уж и thin. А писать код во views быстро и просто. Там сразу и request-объект со всеми данными, и формы, которые эти данные отвалидировали.

Впоследствии размер view начинает постепенно расти и в коде начинают появляться интересные ситуации, например, использование элемента глобального состояния view, такого как request-объект, прямо в бизнес логике, что намертво прибивает эту бизнес-логику к этой view.

Разработчикам удобно использовать глобальное состояние view прямо в бизнес-логике. Некоторые даже не брезгуют доклеивать к нему свои промежуточные вычисления. Это всегда затрудняет чтение кода. Это делает невозможным переиспользование данной бизнес-логики в других местах проекта, таких как celery-задачи, или management-команды. В конце концов это мешает вам адекватно покрыть ваш код unit-тестами. Единственной точкой тестирования в этом случае остается ваш view.

На этом этапе бизнес-логика становится сильно привязанной к инфраструктурному слою (фреймворк/библиотека) вашего проекта.

Каша из Utility Modules

Utility Modules - одна из самых недопонятых концепций в мире Django. Что именно мы должны там хранить? Многие из нас начинают складировать там мусор.

Часто я наблюдаю, что люди даже не пытаются как-то формализовать правила к этому слою в своих приложениях. Все называют его по-разному. Кто-то создаёт в корне проекта файлик utils.py, кто-то создаёт модули helpers или processors. А кто-то - всё это одновременно.

В этих модулях часто могут лежать как и элементы бизнес-логики, так и какие-то универсальные утилиты. Одним словом, каша.

Сервисный слой

Основа концепции сервисного слоя закладывается в понимании разницы между бизнес-логикой и инфраструктурой. Часто разработчики склонны путать эти понятия, поэтому давайте дадим им определения.

Бизнес-логика - это код реализации бизнес-правил. Например, логика списаний с одного баланса и начисление на другой. Слой бизнес-логики является отображением процессов реального мира на программный код.

Код инфраструктуры - это код реализации инфраструктурных процессов, манипулирующий в основном искусственными понятиями, сформулированными сугубо для разработки ПО, например: вью, модели, фреймворки, субд, валидация входных параметров, реквесты, респонсы, API и тд.

Что такое сервисный слой? Давайте тоже попробуем дать определение. Сервисный слой - это такой набор компонентов программного кода, которые инкапсулируют в себе логику приложения. Такие компоненты мы и будем называть сервисами бизнес-логики или доменными сервисами.

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

Если говорить в терминах Django, то целью сервисного слоя будет вынести весь код, относящийся к бизнес-логике приложения, из моделей, view и всех остальных мест, где её быть не должно, вроде middlewares или management-команд, в отдельные модули, оформленные по определенным правилам, оставляя в инфраструктурном слое лишь вызовы из этих модулей.

В рамках сервисного слоя можно выделить также инфраструктурные сервисы. Дело в том, что полностью вынести какие-то инфраструктурные операции за пределы бизнес-логики далеко не всегда возможно. Например, такие операции, как общение с СУБД, запись/чтение диска, хождение по сети. Их-то и можно изолировать в инфраструктурных сервисах, чтобы затем использовать в своей бизнес-логике c помощью более высокоуровневого интерфейса.

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

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

Сервисный слой на уровне структуры проекта

С чего же можно начать формирование сервисного слоя? Начнём с самого простого - структуры модулей. Следует договориться о создании отдельных модулей на уровне каждого Django-приложения. В данной статье в качестве примера будем называть такие модули services:

project_name
├── app_name
│   ├── services
│   │   └── ...
│   ├── tests
│   ├── views
│   ├── models
...

Вы также можете сделать один глобальный модуль сервисов, если у вас, например, мало django-приложений, словом, отталкивайтесь от своего проекта.

Внутри services будут храниться наши модули сервисов. Каждый отдельный модуль сервисов хранит в себе какой-то один бизнес-процесс, объединённый тесным контекстом. Модуль сервиса на уровне структуры проекта может состоять как из одного py-файла, так и из сложного набора подмодулей, организованного исходя из требований вашей бизнес-логики. Соблюдайте баланс, старайтесь не класть несколько сервисов используемых в рамках одного бизнес-процесса в один файл:

services
├── __init__.py
├── complicated_service_example
│   ├── __init__.py
│   └── ...
└── simple_service_example.py

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

Также структуру сервисного слоя можно оформить исходя из разделения на инфраструктурные сервисы и сервисы бизнес-логики.

services
├── __init__.py
├── example_with_separated_service_layers
│ ├── __init__.py
│ ├── infrastructure
│ │   └── ...
│ ├── domain
│ │   └── ...
...  

Сервисный слой на уровне кода

Проектируя код сервисного слоя, в голове следует держать главное правило:

В сервисном слое следует изолировать бизнес-логику от инфраструктуры.

Проектируя сервисный слой, вы должны заставить работать свой фреймворк на свою бизнес-логику, а не наоборот, как это часто происходит в Django-приложениях. Это значит, что вы не должны использовать в коде сервисов бизнес-логики такие вещи, как request-объекты, которые принимают views, формы, celery-задачи, различные сторонние библиотеки, отвечающие за инфраструктурные задачи и т. д. Это правило очень важно. И весь подход к написанию кода отталкивается именно от него. В местах, когда вынести из пайплайна бизнес-логики инфраструктуру невозможно, требуется должным образом её изолировать. Способы изоляции будут описаны далее.

На уровне кода типичный сервис бизнес-логики представляет из себя разновидность паттерна Command, который является производной от паттерна Method Object.

Для примера придумаем простой сервис с минимальным количеством бизнес-логики. Допустим, требуется периодически готовить отчёт о пользователях в системе. Нужно взять все username пользователей, затем сохранить их в csv-файл, имя которого должно быть сгенерировано определенным образом.

Создадим в директории services файл make_users_report_service.py со следующим содержимым:

import csv

from datetime import datetime
from typing import List

from django.contrib.auth.models import User

class MakeUsersReportService:

    def _extract_username_list(self) -> List[str]:     
        return list(User.objects.values_list('username', flat=True))

    def _generate_file_name(self) -> str:     
        return '{}-{}'.format('users_report', datetime.now().isoformat())

    def _load_username_list_to_csv(self, file_name: str, username_list: List[str]) -> str:     
        full_path = f'reports/{file_name}.csv'

        with open(full_path, 'w', newline='') as csv_file:         
            writer = csv.writer(csv_file)
            writer.writerow(['username'])
            writer.writerows(             
                ([username] for username in username_list) 
            )

        return full_path

    def execute(self) -> str:     
        username_list = self._extract_username_list()     
        file_name = self._generate_file_name()     
        return self._load_username_list_to_csv(file_name, username_list)

Такой сервис в виде класса является базовым строительным блоком сервисного слоя. Давайте внимательно рассмотрим его особенности:

1) Используются аннотации типов

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

Если методы вашего сервиса возвращают или принимают инфраструктурные объекты, к примеру, из Django, то это является явным маркером того, что вы что-то делаете не так.

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

2) В коде единственная публичная точка входа

Обратите внимание на метод execute - он является единственной публичной точкой входа в данном сервисе. Всё, что он делает - вызывает под капотом приватные методы в определенном порядке. Такая схема позволяет проще читать код - открыв сервис, сразу видно, в какой последовательности вызывается логика и как её вызывать.

Данный подход помогает в проектировании сервисов. Помните, если вам хочется сделать несколько публичных методов подобных execute в одном сервисе, то это явный признак того, что скорее всего логику нужно разделить и вынести в отдельный сервис.

3) Изолированы обращения к СУБД

Такое инфраструктурное действие, как обращение к СУБД, изолировано в отдельном методе - _extract_username_list. В приватном методe вы можете заменить, к примеру, вызов values_list на raw-sql запрос, или вообще, обращение к некому внешнему API, но при этом ваша бизнес-логика, которой просто нужен список из юзернеймов, всё равно не изменится. Мы зафиксировали интерфейс в примитивах языка.

В данном примере нужны только username-ы пользователей, и поэтому мы можем ограничиться встроенными типами Python - List[str] и не возвращать список объектов модели, ведь Django ORM является такой же частью инфраструктуры как и всё остальное. Более сложные кейсы мы рассмотрим чуть позже.

Выбор, конечно, за вами, но помните, используя queryset-ы напрямую в коде вашей бизнес-логики, вы усложняете себе написание unit-тестов, ведь замокать queryset-ы гораздо сложнее чем просто метод, возвращающий примитив языка. Использование интеграционных тестов Django, которые позволяют вам поднять под капотом тестовую СУБД, важно, но отрабатывают такие тесты гораздо дольше, чем обычные unit-тесты, которые её не используют. А в случае если источником данных выступает некий внешний API стороннего сервиса, то и выбора по сути не остаётся - надо мокать его.

Для тестирования бизнес-логики не нужно каждый раз использовать тестовую базу данных. Ведь для бизнес-логики неважно откуда пришли данные - из СУБД ли, из файла на диске или внешнего API.

Для себя я вывел такую формулу: если возможно, покрывайте ваш сервис на 70% юнит-тестами с замоканным источником данных и на 30% интеграционными тестами, которые умеют поднимать вашу инфраструктуру, частью которой и является ваш источник данных в виде СУБД. Такая практика сделает приятнее разработку по TDD, а также ускорит прохождение тестов в вашем CI/CD пайплайне, что тоже не может не радовать.

4) Изолированы обращения к коду формирования csv-файла

Запись информации в файл на диске - такая же инфраструктурная задача. В принципе, все тезисы, что я перечислил в 3 пункте про СУБД, подходят и сюда - проще тестировать, не надо менять остальной код в случае, если понадобится писать, к примеру, exel файл вместо csv.

5) Название сервиса отражает конкретное действие

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

Только что мы рассмотрели пример очень простого сервиса, состоящего из трёх простых этапов. Бизнес-логики в этом сервисе было весьма мало. В реальности сервисы, конечно же, гораздо сложнее. Давайте рассмотрим, какие проблемы у вас могут возникнуть с кодом выше и как их можно решить в рамках сервисного слоя.

Value Object, DTO, DAO

Давайте представим, что теперь в наш отчёт нужно писать не только username-ы пользователей, но так же и их emal-ы, имена, id и прочее. В рамках сервисного слоя мы стремимся отгородить бизнес-логику от инфраструктуры. А это значит, что вернув список из объектов Django-модели, мы отступим от наших принципов.

Тогда, часть кода выше, отвечающая за запрос к СУБД можно модифицировать следующим образом (реализацию остальных методов пока опустим):

...
from dataclasses import dataclass
from typing import Generator

from django.contrib.auth.models import User

@dataclass
class UsersReportRow:
    pk: int
    username: str
    email: str
    is_active: bool

class UsersReportService:

    def _extract_users_data(self) -> Generator[UsersReportRow]:     
        for user in User.objects.all():         
            yield UsersReportRow(             
                pk=user.pk,             
                username=user.username,
                email=user.email,   
                is_active=user.is_active,
            )
...

Метод _extract_username_list мы заменили на _extract_users_data, который теперь возвращает генератор с Value Object-ами, реализованный в виде дата-класса. Дата-классы - весьма полезный инструмент в разработке на Python.

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

Иногда под Value Object имеют в виду другой паттерн - DTO - Data Transfer Object. С моей точки зрения, DTO - сущность общения между сервисами, в то время как Value Object является сущностью общения внутри сервиса.

Если представить, что наш сервис ,помимо пути к сгенерированному отчёту, должен будет вернуть ещё какую-либо информацию, например, уникальный id отчёта, это могло бы выглядеть так:

...
from dataclasses import dataclass

@dataclass
class UsersReportDTO:
    full_path: str
    report_id: str

class UsersReportService:
...
    def execute(self) -> UsersReportDTO:
        ...
        return UsersReportDTO(
            full_path=full_path,
            report_id=report_id,
        )

Чаще всего, помимо чтения данных, может понадобится и много других операций с хранилищем: создание, обновление данных, агрегация. Как оставить сервис простым и не засорять бизнес-логику кодом работы с хранилищем?

Ответ - изолировать работу с вашим хранилищем через DAO - Data access object. Вот так может выглядеть DAO для взаимодействия с таблицей пользователей в Django:

from dataclasses import dataclass
from typing import Iterable

from django.contrib.auth.models import User


@dataclass
class UserEntity:
    pk: int
    username: str
    email: str
    is_active: bool


class UsersDAO:

    def _orm_to_entity(self, user_orm: User) -> UserEntity:     
        return UserEntity(         
            pk=user_orm.pk,         
            username=user_orm.username,
            email=user_orm.email,
            is_active=user_orm.is_active, 
        )

    def fetch_all(self) -> Iterable[UserEntity]:     
        return map(self._orm_to_entity, User.objects.all())

    def count_all(self) -> int:
        ...

    def update_is_active(self, users_ids: Iterable[int], is_active: bool) -> None:  
        ...

Таким образом, в коде сервиса вашей бизнес-логики остаётся только использование DAO без построения запросов к СУБД напрямую.

Хочу ещё раз обратить внимание - мы специально не используем объекты моделей Django. Заставляя двигать данные внутри нашего сервисного слоя через примитивы языка и пользовательские объекты, мы изолируем нашу бизнес-логику от инфраструктуры.

Изолирование работы с ORM в коде обычно вызывает больше всего негативных эмоций у Django-разработчиков. Думаю, это происходит в первую очередь из-за того, что очень часто доменная модель бизнес-сущностей накладывается на модели Django в начале разработки новой фичи.

Может быть, такая изоляция и выглядит избыточной, когда в примере можно сделать всего один простой запрос в ORM, но поверьте, если для бизнес-логики вам в какой-то момент потребуется не просто достать набор строк из таблицы, а собрать некий агрегат, делая несколько запросов в разные источники данных, или сделать raw-sql запрос через драйвер к СУБД, который возвращает вместо адекватного объекта какой-то tuple из tuple-ов, то помимо всех достоинств, описанных ещё в предыдущем более простом примере, вы получите ещё и улучшенную в разы читаемость кода.

Так же весьма важным эффектом является то, что изолируя ORM, если в какой-то момет вам придётся заменить источник данных, к примеру, на MongoDB, или вообще, веб-API вашего другого сервиса, вам не придётся переписывать кучу unit-тестов и всю бизнес-логику. Нужно будет только переписать тесты на ваш DAO или метод сервиса, который возвращает DTO/Value Object. Главное лишь то, чтобы ваш код изолирующий работу с данными сохранял старый интерфейс. Сделайте вашу инфраструктуру зависимой от бизнес-логики, а не наоборот!

Dependency injection - построение комплексных сервисов

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

Теперь давайте снова усложним наш пример. Представим, что заказчик захотел, чтобы помимо csv-файла была так же возможность сгенерировать и exel-файл.

Создадим два новых инфраструктурных сервиса, затем встроим их в наш сервис бизнес-логики. Один из них будет отвечать за запись xlsx, а второй - за csv.

Модифицируем исходный файл make_users_report_service.py (снова опустим подробности реализации):

...
import abc
from typing import Iterable

class IReportFileAdapter(abc.ABC):

    @abc.abstractmethod
    def create_report_file(self, file_name: str, username_list: Iterable[UsersReportRow]) -> str:     
        pass

...

class UsersReportService:

    def __init__(self, report_file_adapter: IReportFileAdapter):     
        self.report_file_adapter = report_file_adapter

    def _extract_users_data(self) -> Generator[UsersReportRow]:     
        ...

    def _generate_file_name(self) -> str:     
        ...

    def execute(self) -> str:     
        username_list = self._extract_users_data()     
        file_name = self._generate_file_name()     
        return self.report_file_adapter.create_report_file(file_name, users_data_list)

И далее, создадим новый файл с инфраструктурными сервисами, реализованными в виде адаптеров  report_file_adapters.py:

import abc
from typing import Iterable

from .make_users_report_service import IReportFileAdapter

class CSVReportFileAdapter(IReportFileAdapter):

    def create_report_file(self, file_name: str, username_list: List[str]) -> str:     
        ...

class XLSXReportFileAdapter(IReportFileAdapter):

    def create_report_file(self, file_name: str, username_list: List[str]) -> str:     
        ...
      

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

from your_django_app.services.reports import (
    UsersReportService,
    CSVReportFileAdapter,
)

users_report_service = UsersReportService(report_file_adapter=CSVReportFileAdapter())
path_to_report = users_report_service.execute()

Давайте рассмотрим написанный код подробнее:

1) Inversion of Control

С помощью абстрактного базового класса мы эмулировали интерфейс в нашем коде и положили его именно рядом с нашей бизнес-логикой, а не адаптерами. Таким образом, мы смогли достичь Инверсии управления в нашем коде. Благодаря этому в файл с бизнес-логикой не нужно делать импорты инфраструктурных сервисов, которые умеют писать csv/xlsx. Мы добились зависимости инфраструктурного слоя от бизнес-логики, а не наоборот.

Вы так же можете достичь IoC с помощью типа Protocol, появившегося в typing начиная с python 3.8.

Многие считают IoC в python излишним. Применяйте по ситуации: если вам не нужна высокая степень изоляции компонентов, можно обойтись и без IoC, либо использовать абстрактные базовые классы с реализацией, которые уже следовало бы держать рядом с адаптерами в моём примере. Сервисный слой гибок.

2) Удобный mock

Одному мне не нравится каждый раз писать в тестах длинный @mock.patch('...')? Длинный путь к объекту, который вы хотите замокать, банально неудобно читать и прописывать. К тому же, при перемещении или переименовании объекта, который вы мокаете, эту строку нужно будет не забыть поправить. Теперь всё можно сделать гораздо приятнее. Встраивая сервисы друг в друга, при написании тестов, вы получаете возможность пробрасывать Mock при инициализации вашего сервиса:

from mock import Mock
from unittest import TestCase

from your_django_app.services.reports import (
    UsersReportService,
    IReportFileAdapter,
)


class UsersReportServiceTestCase(TestCase):

    def test_example(self):
        report_file_adapter_mock = Mock(spec=IReportFileAdapter)
        users_report_service = UsersReportService(
            report_file_adapter=report_file_adapter_mock
        )
        ...
...

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

О любви Python-сообщества к библиотекам и зависимости от инфрастурктуры

Что делают в python-сообществе когда возникает проблема? Правильно - пишут новую awesome-библиотеку (и теперь у нас две проблемы). Идея сервисного слоя не нова, и библиотеки на эту тему уже есть.

https://github.com/mixxorz/django-service-objects - автор предлагает писать сервисный слой на основе Django-форм. С моей точки зрения, валидация входных данных должна происходить в инфраструктурном слое, а не перегружать собой слой бизнес-логики. На слое сервисов можно валидировать только бизнес-правила. А всякие проверки, что число - это число, а не строка, лучше оставить обычным Django-формам.

https://github.com/dry-python/stories - ещё одна библиотека для построения сервисного слоя. Давно слежу за ребятами. Помимо stories, у них много других интересных библиотек на разные темы.

Я против использования подобных библиотек. И вот почему:

1. Сторонняя библиотека - это уже часть инфраструктуры, сама по себе. Завязывая вашу бизнес-логику на такую библиотеку, вы заранее завязываете свою бизнес-логику на инфраструктуру, что уже противоречит идеи разделения бизнес-логики и инфраструктуры на разные слои. Однажды вам может понадобится выйти за рамки вашей библиотеки для написания бизнес-логики, и, скорее всего, это будет больно. Сильно задумайтесь, нужно ли вам это.

2. У многих в голове стереотип, что Python - язык для data science и каких-то DevOps-скриптов, и без дополнительных приседаний в виде специальных библиотек, нормально оформить в нём сложную бизнес-логику нельзя. Естественно, это не правда. Python давно готов для написания серьезных приложений с нагруженной бизнес-логикой. В этой статье я привёл примеры разных приёмов, которые не требовали сторонних зависимостей для описания бизнес-логики. Если вам захочется выйти за рамки описанного в статье, вы будете ограничены лишь языком программирования, а не какой-то библиотекой.

Сервисный слой должен оставаться гибким, и подходить потребностям вашей команды. Имейте это в виду, если всё-таки решитесь завязать ядро вашего приложения, которым является ваша бизнес-логика, на какую-то библиотеку.

Что дальше?

Лучше всех по теме негативных последствий от зависимости бизнес-логики от инфраструктуры приложения уже высказывался Роберт Мартин в своих статьях "Screaming Architecture" и "The Clean Architecture", а также прекрасной книге "Clean Architecture: A Craftsman's Guide to Software Structure and Design".

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

Вы могли видеть в данной статье элементы Domain-driven design. Для ознакомления рекомендую обратить внимание на книгу "Domain-Driven Design: Tackling Complexity in the Heart of Software" от Эрика Эванса. Сервисный слой можно также развить в полноценное DDD приложение.

---

Подводя итог

Итак, подведём итог нашему путешествию в сервисный слой:

1. Начните со структуры - заведите отдельный модуль для вашего сервисного слоя и хорошо структурируйте его.

2. Сервисы бизнес-логики оформляются в виде классов-команд (классов с одним публичным методом). Инфраструктурные - по ситуации.

3. Трафик данных в сервисах, а также между ними, лучше всего осуществлять в примитивах языках и пользовательских объектах с помощью Value Object, DTO, DAO.

4. Больше тестов! Покрывайте сервисы тестами, активно мокайте инфраструктуру и другие сервисы от которых вы зависите.

5. Сервисы могут быть комплексными и вызывать под капотом другие сервисы. Такое взаимодействие будет удобно организовать через Dependency Injection.

6. Сервисный слой должен подходить потребностям вашей команды. Опасайтесь завязки на чужие решения в виде библиотек или фреймворков. Используйте только те приёмы, что вы считаете нужными. Возможно, просто вынесение кода из ваших views, без серьезной изоляции инфраструктуры, может решить большинство ваших проблем.