Closed chrismatix closed 3 years ago
The first approach that comes to mind is backend/lib/message
that could expose something like MessageRepository.updateState(Message message,DeliveryState newState);
(naming all up for discussion)
It's good for me, but it feels like it's far from complete, because remembering that updateState
exists requires as much domain knowledge as knowing how to set these fields (for now).
So it's good, but long term I think we have to customize our avro generator pipeline 🙏
I like the Repository
approach, as long as we encapsulate all logic of that object (including building it)
It's good for me, but it feels like it's far from complete, because remembering that
updateState
exists requires as much domain knowledge as knowing how to set these fields (for now).So it's good, but long term I think we have to customize our avro generator pipeline 🙏
while it's true required knowledge is basically the same, this would still be a little less error-prone (and also introduce some sort of new pattern)
I like the
Repository
approach, as long as we encapsulate all logic of that object (including building it)
I'm not 100% about the building part as the Avro builder seems pretty good. I would argue we have a sketch idea of what we want to do so I will remove the needs discussion label and move it to do. We can sort out details in the pull request
I'm not 100% about the building part as the Avro builder seems pretty good. I would argue we have a sketch idea of what we want to do so I will remove the needs discussion label and move it to do. We can sort out details in the pull request
If at some point we want to do a full builder I would prefer that we extend the avro tools a bit. It's doable.
So for now I would do it the cheap way:
backend/avro/communication/message
hosts a java class MessageRespository
that does what @lucapette described. We replace all direct state updates with usages of that class.
Is this sketch detailed enough?
yes! that's why I had removed the needs discussion label. The details can be figured out in the PR itself
Current state We have implicit semantics on the generated message avro class. E.g.
updatedAt == null
implies that this is a new message.In order to allow for safe interactions with the message object across sources and core apps we need an accessor abstraction.
_Originally posted by @lucapette in https://github.com/airyhq/airy/pull/275#discussion_r521893265_