Как правильно располагать абстрактные классы, имеющие разные ответственности?

Question

[Леонид ---]

Здравствуйте! Есть вопрос насчёт расположения в проекте интерфейсов. Я думаю многим известна эта картинка:


По дефолту мы располагаем сущности и интерфейсы в ядре (по крайней мере, у меня так сделано) - слой core или domain. Но что если у меня в core.interfaces.py лежат абстрактные классы (интерфейсы):
1) класс, ответственный за репозиторий (методы загрузки и выгрузки данных из файла в память и обратно);
2) класс, ответственный за конвертацию пользовательского объекта в словарь и обратно
3) класс, ответственный за то, по какому алгоритму будет формироваться новый id для добавления записи в бд;

Пример:



Реализации этих интерфейсов лежат по разным слоям/папкам, а вот сами интерфейсы в одном месте - модуле interfaces.py

С точки зрения чистой архитектуры стоило бы переложить интерфейсы туда, где лежат их реализации ( в одну директорию), но добавить в каждый слой, подслой core (т. е. ядро именно для этого слоя), куда бы мы и положили интерфейсы?

Answer 1

[fenrir]

С точки зрения чистой архитектуры стоило бы переложить интерфейсы туда, где лежат их реализации ( в одну директорию), но добавить в каждый слой, подслой core (т. е. ядро именно для этого слоя), куда бы мы и положили интерфейсы?

Можно хоть так хоть так. Кто-то кладет все "вертикально" (все слои одного домена), кто-то "горизонтально" (по слоям). У обоих подходов есть плюсы и минусы.

2) класс, ответственный за конвертацию пользовательского объекта в словарь и обратно
3) класс, ответственный за то, по какому алгоритму будет формироваться новый id для добавления записи в бд;

Придумают же тащить джаву в питон... По пункту 2 достаточно описать Protocol и просто реализовывать методы в классе без всей этой ментальной гимнастики. По 3 пункту вообще не понимаю в чем смысл целого класса чтобы формировать id, но как будто достаточно просто создать функцию и при необходимости заменить ее реализацию.
Все интерфейсы, не имеющие двух реализаций не нужны.
Все интерфейсы обмазанные Any не нужны.
Все интерфейсы, которые приходится менять потому что надо поправить параметры реализации не нужны.

Answer 2

[Пума Тайланд]

а кто вызывает create_new_id и to_dict/from_dict? если только реализация репозитория (файл, json), то это детали хранения, в core им делать нечего, клади рядом с реализацией. В core остаётся то, что зовёт сам use case: IRepository и генератор id, если id нужен до сохранения. Правило простое: интерфейс принадлежит тому, кто его вызывает, а не тому, кто реализует. Отдельный core в каждом слое не нужен, только лишние папки.

Comments

[Olesya Dekhand]

Переносить интерфейсы во внешние слои к их реализациям — это грубая архитектурная ошибка. Это полностью разрушает главное правило Чистой Архитектуры — направление зависимостей.
Согласно луковой структуре, все зависимости должны быть направлены строго внутрь (к ядру). Внутренние слои (Domain / Core) понятия не имеют, какая инфраструктура находится снаружи (база данных, файлы, UI). Если вы перенесете интерфейсы в папки к реализациям, то ваше ядро будет вынуждено импортировать их из внешних слоев. Это породит запрещенную обратную зависимость «Ядро ➡️ Инфраструктура».
Интерфейс всегда принадлежит вызывающему коду (тому, кто его использует), а не вызываемому (реализации). Разносить интерфейсы нужно не к реализациям, а по функциональным зонам самого ядра, чтобы не нарушать принцип разделения интерфейса (ISP из SOLID).
Где правильно расположить ваши интерфейсы:
Интерфейс репозитория (работа с файлом/БД): Оставляем в Core (Application/Domain). Бизнес-логике приложения нужно знать, какие действия можно совершать с данными (сохранить, получить), но ей плевать на физический носитель. Реализация уходит в слой инфраструктуры и импортирует этот интерфейс из ядра.
Класс для генерации нового ID: Это чистое доменное правило, определяющее логику сущности. Абстракция должна лежать в самом центре — в Domain Model.
Класс для конвертации объекта в словарь (Serializer): Зависит от того, для чего он нужен. Если для отдачи данных в UI/API — интерфейс лежит на границе Application Services / Presenters. Если для сохранения в файл — в инфраструктурном шлюзе.
Примечание для Python:
для обычного перевода объекта в dict абстрактные классы часто избыточны, лучше использовать методы самой сущности или библиотеки вроде Pydantic.Идеальная структура директорий:Не нужно плодить «подслои core» внутри инфраструктуры.
Разнесите код в ядре по смыслу:

my_project/
│
├── core/ (Слой Domain / Core — не зависит от внешнего мира)
│ ├── domain/
│ │ ├── models.py # Сущности бизнес-логики
│ │ └── id_generator.py # ABC для генератора ID (Доменное правило)
│ │
│ └── application/
│ ├── interfaces.py # ABC для Репозиториев и внешних сервисов
│ └── use_cases.py # Логика приложения, использующая эти ABC
│
└── infrastructure/ (Внешний слой — импортирует и реализует интерфейсы ядра)
├── file_repository.py # Реализация репозитория (работа с файлом)
├── db_id_generator.py # Реализация генератора ID
└── serializers.py # Конкретные мапперы

[Пума Тайланд]

Oleca, так я ровно это и говорил: интерфейс принадлежит тому, кто его вызывает. Если create_new_id/to_dict дёргает только файловый repo, а не use case, то это деталь реализации, и отдельный ABC под неё в core тащить незачем — а не "core должен зависеть от infra".

[Леонид ---]

Ребята, извините, пожалуйста, определитесь между собой и объясните, мне, чайнику, как лучше сделать. Если у меня одни реализации (TransactionCreatorOfNewId, TransactionSorter) интерфейсных классов (вместо самих интерфейсов ICreatorOfNewId, ISorter) - лежат там, где они используются. Другая - одна реализация JsonRepository лежит в инфраструктуре, т. е. там, где нет других мест в этом модуле, где вызываются методы этой реализации. Помогите.

[Пума Тайланд]

XaoTikS, у вас всё как раз норм: TransactionCreatorOfNewId и TransactionSorter пусть лежат рядом с тем, кто их вызывает, если больше нигде не нужны. А JsonRepository — в infrastructure, IRepository — в core, потому что core вызывает репозиторий именно через этот интерфейс.

[Леонид ---]

Пума Тайланд, Так получается это реализации интерфейсов должны лежать там, где они используются, а сами интерфейсы в core/???

[Леонид ---]

Пума Тайланд, Это классический подход: контракт живёт в том слое, который его определяет - не лучше ли так будет делать?

Answer 3

[KrimsN]

Соглашусь со всем написанным выше. На самом деле нет единой "правильной" раскладки, которая решала бы все вопросы, у каждого варианта есть свои плюсы и минусы.
Я бы для python сейчас рассматривал go подход, без абстрактных классов, использовать только интерфейсы (Protocol) и объявлять их рядом с пользователями, там где этот протокол нужен (или рядом).
Если нужна "базовая" реализация, использовал миксины, или просто функции хелперы, и раскладывал иерархию "плоско" на утиной типизации и реализации протоколов, без чёткой структуры наследования, которая в python не даёт ничего, кроме 2 вещей, оверинжениринга и возможности выстрелить себе в ногу позже.