Multi-tenancy logic related to repository, usecase or handler layer? about 8am

[hatajoe]

@frederikhors I'm sorry for the late reply, and thank you for giving me a question.

Where do you think I should do something like below? In handler, usecase or repository?

First, I think the point is your application boundary.
Regarding a multi-tenancy application, the data referred by API are always bounded by specified tenant. Thus I think the handler has a responsibility to solve the boundary of the application, because of the layer below handler doesn't want to have a concerning about any other tenant.
The domain (and usecase) layer should solve an application concerning of specified tenant simply.

I think maybe the concept of FilterByTenant in the usecase layer is an unnecessary repetition and should belong to lower levels like repositories?

Yes, I think better to put FilterByTenant to the repository.
You can inject tenant_id to repository when it is initialized like following.

repo := NewUserRepository(ctx, tenant_id)

But, I think better to treat tenant_id as a context data.
I said the multi-tenancy application's tenant_id is to solve application boundary, I think it is the same as an application context data.

So, I will try to implement FilterByTenant as following:

repo := NewUserRepository(ctx)

---

type UserRepository strurct {
   ctx context.Context
}

func (r *UserRepository) FilterByTenant() *Users {
    tenant_id := ctx.Value('tenant_id')
    ...
}

[hatajoe]

I close this, thanks.