Как правильно смоделировать сущность User по принципам Clean Architecture?

Question

[Aleksey Solovyev]

В рамках проектирования системы по принципам чистой архитектуры, возник вопрос границ. Есть некая сущность UserEntity, содержащая обязательное поле id, которое генерируется СУБД (автоинкремент). Есть интерфейс UserRepositoryProtocol имеющий метод create, принимающий UserEntity и возвращающий её с присвоенным id.
Простой пример на python (язык роли не играет):

@dataclass(frozen=True, slots=True)
class UserEntity:
    id: int
    ...

class UserRepositoryProtocol(Protocol):
    async def create(self, user: UserEntity) -> UserEntity:
        ...

Получается что-то такое:

app/
├── domain/
│   ├── entities/
│   │   └── user_entity.py
│   └── repositories/
│       └── user_repository.py

Однако возникает непонимание: поскольку идентификатор id генерируется на уровне базы данных и становится доступным только после выполнения операции сохранения, возникает вопрос: что именно передавать в метод create репозитория, если экземпляр UserEntity не может быть создан без этого обязательного поля?

Какие решения я вижу:
- указать поле id как опциональное (Optional[int]), однако это искажает семантику модели - идентификатор должен быть гарантированно присутствующим атрибутом полноценной сущности
- выделение отдельной структуры, условно UserCreate, выступающей в роли DTO, используемого исключительно для создания пользователя (не путать с DTO в слое application)
- реализовать собственный механизм генерации идентификаторов. Например, внедрить отдельный value object UserId, который будет генерировать уникальное значение (UUID)

Ни один из вариантов не кажется мне "правильным" (хоть слово правильно тут совсем неуместно)

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