Big Thank you - along with few quick questions around "WorkshopManagementAPI"

[CodeWithKashif]

Thanks a lot @EdwinVW for helping community by sharing such an awesome work, great help for us.
This is one of the best code repository I have found so far on

I have following quick questions kindly help.

1. Why did you sagrigated "WorkshopManagementAPI" and "WorkshopManagementEventHandler" project.
   I think "WorkshopManagementEventHandler" can be merged under "WorkshopManagementAPI" project
   since "WorkshopManagementAPI" is most important part and that should be always up and running so its event handler should be there as well.
   kindly let us know your thoughts/vision

2. Since you are saving customer data in all databases then why didn't you save that(customer data) in "VehicleManagement" database. any special case?

3. Q 3) What is purpose of defining special RefDataController and what does refdata means here?

4. What does "fanout" means
   model.ExchangeDeclare(_exchange, "fanout", durable: true, autoDelete: false);

Waiting for your response.

[EdwinVW]

Hi @findkashif. Thanks for that great compliment!

Regarding your questions:

1. The reason for separating the API and eventhandler, is autonomy of the individual services. The eventhandler will ingest events from other domains (customer / vehicle) even when the API is offline for maintenance. It's all about separation of concerns and the ability to release components with a different release cadence.

2. The reason is mainly for demonstration purposes. Within Pitstop, I use 2 mechanisms for getting data from other domains: through events (as with the Invoiceservice for instance) or by calling an API at the moment you need the data (as with the VehicleManagementAPI). In every scenario, you should choose one or the other mechanism - fit for your requirements. Do you want availability: choose the event way. If availability is less important and you need consistency, choose for getting the data from the system of record at the time you need it (this creates a runtime dependency).

3. Within the WorkshopManagement domain, I've chosen to name the cached customer and vehicle data (received through events) "reference data" because it is created in a different domain. Also, the reference data is a relational read-model whereas the state of the WorkshopManagementAPI is stored in an event-store. For separation of concerns, I've separated these two in separate controllers and repositories.

4. A fanout exchange in RabbitMQ is the simplest way of doing pub/sub. A message sent to this exchange is simply copied to all queues bound to the exchange. This is all I needed for Pitstop, so I picked this exchange type (see also: the RabbitMQ docs).

I hope these explanations are clear and answer your questions @findkashif!

[CodeWithKashif]

Thanks a lot for such a detail answer, now I am very much aligned with your vision.

Thanks for teaching this
"Do you want availability: choose the event way. If availability is less important and you need consistency, choose for getting the data from the system of record at the time you need it (this creates a runtime dependency)."_

I have few more questions around event storing, that i will be posting that in a different thread.