Should UserIdGenerator really be considered a domain concept?

[dbealthy]

I started following structure from this great example to implement clean architecture in my project. While implementing the CreateUserInteractor use case, i noticed that UserService depends on UserIdGenerator from domain layer. But in my case i want user id to be auto incremented, so i would have to pull that id from db, and it would be an application level concept then.

[ivan-borovets]

Thanks for the warm feedback about the project — glad it's been helpful!

I see what you're running into. Whether UserIdGenerator belongs in the domain really depends on how you handle ID generation. It's likely unnecessary if IDs are assigned by the database (e.g. via auto-increment). In that case, you can use a placeholder like UserId(0) and let the DB assign the real ID later:

1. Value object for ID

@dataclass(frozen=True, repr=False)
class UserId(ValueObject):
    value: int

2. User Service

def create_user(self, ...) -> User:
    user_id = UserId(0)
    ...
    return User(id_=user_id, ...)

3. Users Table Mapping

users_table = Table(
    "users",
    mapping_registry.metadata,
    Column("id", Integer, primary_key=True, autoincrement=True),
    ...
)

def map_users_table() -> None:
    mapping_registry.map_imperatively(
        User,
        users_table,
        properties={
            "_id_raw": users_table.c.id,
            "id_": composite(UserId, users_table.c.id),
            ...
        },
        column_prefix="_",
    )

4. User Data Mapper

class SqlaUserDataMapper(UserCommandGateway):
    ...
    async def add(self, user: User) -> None:
        if user.id_.value == 0:
            setattr(user, "_id_raw", None)

        self._session.add(user)

If you're switching from UUIDs, just make sure to update the rest of the code accordingly.

[dbealthy]

Thanks. The example helped a lot.

I was thinking about moving UserIdGenerator into the application layer and implementing it in the infrastructure layer, querying next id from db like this:

SELECT nextval(pg_get_serial_sequence('users', 'id'));

[ivan-borovets]

I think it might be tricky to avoid desynchronization — you're reserving an ID before actually inserting the user, so if the insert fails, that ID is lost. There's also a race condition risk: two processes could fetch IDs at the same time, but only one succeeds with the insert.

Since you're already leaning towards using auto-increment, it might be easier to stick with that and let the DB handle ID assignment at insert time.

UPD: See my corrected response below.

[ivan-borovets]

@dbealthy

Apologies! I missed the atomic nature of nextval(), so race conditions aren't an issue here. As for lost IDs, the manual approach would result in more gaps, since the window between reservation and insertion is wider — but this likely won't be a major concern if you're choosing auto-increment anyway. Still, the manual approach essentially duplicates logic that the database already handles efficiently.