Опа, а что такое структурно/датаклассово-реляционное отображение?

Я имел в виду анемичную модель данных, в противовес богатой. Не лучший термин подобрал

Не уверен, но для инкапсуляции бизнесовой логики как будто есть Entity и агрегаты с фабриками, а ORMкой можно реализовать Repository, который будет с ними связан.

Та же сессия из sqlalchemy или например entity framework из .net и так реализуют паттерн репозиторий. Крутить поверх него что-то сверху выглядит сомнительным.

Энтити, агрегаты и вэлью обжекты как-то должны быть сохранены и загружены из базы данных. Энтити, агрегаты и VO это объекты. Orm как раз и позволяет сохранять и загружать объекты.

Давно не читал сложно о простом

мне трудно это подтвердить или опровергнуть т.к. я не работал с ORM в целом как с явлением. только в общих чертах представляю что это и как работает.

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

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

По поводу репозитория и его места в слоях пока что не готов ответить сходу.

По поводу наследования сущностей от базовых классов — вы абсолютно правы. Но наследовать свои сущности от базовых классов никто не обязывает. Классы, находящиеся в доменном слое можно маппить в инфраструктурном слое при помощи императивного марпинга в той же алхимии https://docs.sqlalchemy.org/en/20/orm/mapping_styles.html#imperative-mapping .

Так зависимости будут направлены в нужную сторону

Да, посмотрел, подумал, судя по всему всё же надо делать свой репозиторий.

В домене интерфейс, в инфре реализация вокруг сессии алхимии.