0

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?

marc_s
  • 732,580
  • 175
  • 1,330
  • 1,459
PelikanFix16
  • 23
  • 4
  • By _user context_ do you actually mean a _user transaction_, created on a user request and committed after the request processing is complete? – Farhan Nasim Jun 09 '22 at 19:17
  • 1
    Please provide enough code so others can better understand or reproduce the problem. – Community Jun 10 '22 at 09:48
  • Kindly provide snippet of your code or demonstrate any high level design view so others can see it clearly thank you. – Francis Decena Jun 11 '22 at 08:47

1 Answers1

0

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.

Nightlord
  • 56
  • 5
  • But when I implement internal event handler, this event should come from rabbitmq (event bus) or should be passed to event handler bypassing event bus? – PelikanFix16 Jun 11 '22 at 23:39
  • I'm confused by the difference between "rabbitmq(event bus)" and "bypassing event bus" can you explain it? – Nightlord Jun 12 '22 at 11:23
  • The implementation of my team is to convert the internal event as an external event in the internal event handler, which will post the external event to the event bus. We've defined a class for modeling the external event. All kinds of internal events can be converted as an external event. – Nightlord Jun 12 '22 at 11:28
  • Bypassing event bus, I mean instantly passing events from CQRS handler to event handler witchout putting them into event bus – PelikanFix16 Jun 12 '22 at 15:12
  • I see. Thanks for clarifying it. Well, I think more information for the architecture might be needed to understand your design. Anyway, as I said, we did put the internal events to event bus instead of calling event handler directly. It's because there might be more than one event handler being interested by an internal event. By passing the events to the event bus, the provider doesn't need to recognize all the event handlers for a single event. Thus, you can add/remove the event handler easier without modifying the provider, as the application evolved. – Nightlord Jun 12 '22 at 23:09
  • I think these are quite detailed for the design, and could be varied according to the different context. So be willing to take a different approach, as long as you understand what options you'd got and why you made the decision. – Nightlord Jun 12 '22 at 23:12