I'm creating a project using event sourcing and DDD techniques, for fun and learning.
Actually I think about projections in my project, where to locate their ports and adapters.
At this time, I'm creating user context. I think interfaces/ports for repository of this projections should be located in application core, also projection model should be located inside application core, implementation for this repository should be inside infrastructure layer. Now the question is if event was thrown, UserRegisteredEvent, this event is saved to event store and pass to message bus, did the same user context should handle this event from event bus and create projections inside this handler and persist projection inside database using repository and projection model. Maybe this is overkill and if event is from the same context, projection should be created in CQRS handler when storing event in event store?
did the same user context should handle this event from event bus and create projections inside this handler and persist projection inside database using repository and projection model
Assuming what you mean for user context is "Bounded Context"(BC) in DDD.
It is not weird for an event listener to listen to the events from the same BC, which is often used to synchronize the states between the aggregates, to decouple the aggregates.
These are the internal domain event, while the domain events for crossing BC are referred as external events.
Maybe this is overkill and if event is from the same context, projection should be created in CQRS handler when storing event in event store?
So I won't consider it overkill. You need to implement an event handler listening to all the internal events for projecting your read model.
This makes sense since the read model can be varied, according to your requirement, while you are having the same write model (or domain model, in general). You don't want your write model depending on the read model.