После долгих раздумий и экспериментов с различными архитектурами, я, наконец, пришел к своей версии чистой архитектуры для проектов на Django. Эта структура позволяет мне организовать код так, чтобы он был независим от фреймворка и легко поддерживался. В этой статье я подробно расскажу о своей архитектуре, объясню концепции DTO (Data Transfer Object) и Entities, а также поделюсь опытом, который я приобрел в процессе.

Структура проекта

Ниже представлена структура моего проекта:

my_project/
├── core/
│   ├── entities/
│   ├── dto/
│   ├── services/
│   └── repositories/
├── infrastructure/
│   ├── django/
│   │   ├── models/
│   │   │   ├── user_model.py       # Модель для пользователя
│   │   │   └── post_model.py       # Модель для поста
│   │   ├── views/
│   │   │   ├── user_views.py        # Представления для пользователя
│   │   │   └── post_views.py        # Представления для поста
│   │   ├── serializers/
│   │   │   ├── user_serializer.py    # Сериализатор для пользователя
│   │   │   └── post_serializer.py    # Сериализатор для поста
│   │   ├── urls/
│   │   │   ├── user_urls.py          # URL конфигурация для пользователя
│   │   │   └── post_urls.py          # URL конфигурация для поста
│   │   └── apps.py                   # Конфигурация приложения
├── tests/
└── manage.py

Основные компоненты архитектуры

1. Core (ядро)

Этот уровень отвечает за бизнес-логику приложения и включает в себя несколько ключевых компонентов:

• Entities: Сущности представляют собой основные объекты бизнес-логики. Например, в нашем случае сущностями могут быть User и Post. Они содержат состояние (данные) и методы, которые определяют поведение объектов.

• DTO (Data Transfer Object): Это объект, который используется для передачи данных между процессами. DTO помогает избежать зависимостей между слоями приложения, позволяя передавать только необходимые данные. Например, при регистрации пользователя можно создать DTO, который будет содержать только поля, необходимые для этой операции (имя, email и т. д.).

• Services: Сервисы содержат бизнес-логику и обеспечивают взаимодействие между сущностями и репозиториями. Например, в сервисе UserService можно реализовать методы для создания и обновления пользователей.

• Repositories: Репозитории отвечают за взаимодействие с базой данных. Они абстрагируют логику доступа к данным и позволяют легко изменять реализацию хранилища. Например, UserRepository будет отвечать за все операции, связанные с пользователями.

2. Infrastructure (инфраструктура)

Этот уровень отвечает за реализацию фреймворка и включает:

• Django: Здесь находятся модели, представления, сериализаторы и конфигурация URL.

• Models: Модели представляют собой представление данных в базе данных и определяют структуру таблиц. Например, user_model.py может содержать модель User, которая описывает структуру таблицы пользователей.

• Views: Представления отвечают за обработку запросов и взаимодействие с сервисами. Они получают данные от пользователя и передают их в сервисы для обработки.

• Serializers: Сериализаторы используются для преобразования данных между форматами (например, из модели в JSON и обратно). Они также могут выполнять валидацию входящих данных.

• URLs: Конфигурация URL определяет маршруты, по которым будут доступны представления.

Пример реализации

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

Сущность (core/entities/user.py)

class User:
    def __init__(self, username: str, email: str):
        self.username = username
        self.email = email

DTO (core/dto/user_dto.py)

class UserDTO:
    def __init__(self, username: str, email: str):
        self.username = username
        self.email = email

Сервис (core/services/user_service.py)

from core.entities.user import User
from core.repositories.user_repository import UserRepository

class UserService:
    def __init__(self, user_repository: UserRepository):
        self.user_repository = user_repository

    def create_user(self, dto: UserDTO) -> User:
        user = User(username=dto.username, email=dto.email)
        return self.user_repository.save(user)

Репозиторий (core/repositories/user_repository.py)

from infrastructure.django.models.user_model import UserModel

class UserRepository:
    def save(self, user):
        user_model = UserModel(username=user.username, email=user.email)
        user_model.save()
        return user

Преимущества чистой архитектуры

• Модульность: Каждый компонент отделен от других, что облегчает тестирование и поддержку.

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

• Чистота кода: Логика приложения становится более читаемой и структурированной, что упрощает процесс разработки.

Заключение

Я наконец пришел к своей чистой архитектуре и организации кода внутри проектов Django. Эта структура позволяет мне создавать приложения, которые легко поддерживать и расширять. Разделение на уровни, использование DTO и Entities помогает избежать запутанности и обеспечивает гибкость при работе с бизнес-логикой. Я уверен, что такая архитектура будет полезна не только мне, но и другим разработчикам, стремящимся к качеству и чистоте кода.