Giters

CodelyTV / php-ddd-example

🐘🎯 Hexagonal Architecture + DDD + CQRS in PHP using Symfony 6

Home Page:https://pro.codely.tv/library/ddd-en-php

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Model `MessageId` <- `EventId`|`RequestId` <- `QueryId`|`CommandId`

JavierCane opened this issue · comments

commented

Based on the discussions regarding this PR.

We should model the MessageId <- EventId|RequestId <- QueryId|CommandId hierarchy being Value Objects wrapping a Uuid. We should also model their corresponding test stubs.

commented

I think we should delete that RequestId coming from outside (and we could generate it directly inside every message). In order to improve the developer UX

commented

I don't know if I'm missing anything, but if we generate the RequestId from the inside of the backend, we will not be able to met the goal of the RequestId: Avoid processing duplicated requests coming from the frontend.

I mean, the goal of the RequestId parameter is helping to identify requests coming form the client which are already being processed in an asynchronous process, and successfully replying to the client without queueing again that same job.

Let's figure out that we would be modelling the communication for the AWS CodeDeploy service. The use case would be:

  1. Client: Hey Backend! Please, create the deploy number 123456 for the deploy group abc. BTW, this is the request 123.
  2. Backend: Hey Client! I will be delighted to do so, but in an async way, so I accept your 123 request, and I would ask you to wait until I send another message through this full-duplex communication channel informing about the deploy completion
  3. Client: Hey Backend! I'm a little bit messy implemented, so please, create the deploy number 123456 for the deploy group abc. BTW, this is the very same request 123.
  4. Backed: Yep, I already heard you. I'm accepting your request because it doesn't contain any error and I have to be idempotent. However, I will not queue again that request 123 because I'm already processing it.
  5. Some time passes
  6. Backend: Hey Client! Your deploy number 123456 for the deploy group abc has been successfully done. BTW, this response correspond to the request 123. Thanks for being listening!

That is, I completely understand the complexity added by the RequestId while testing and modelling our request & responses. However, I find it quite useful because of being able to avoid processing duplicated requests in an async environment. So I'm completely open to any other way of implementing something else which allow us to met this very same goal, but I can't find other ways simpler than that (hashing the request parameters could be even more complex, doesn't it?) :/

Thanks!