Managing a connection to an external component in an Aggregate

Imported from Google Groups
#1

Hello,

I just discovered Axon framework and am very eager to use it as it answers a lot of my questions and concerns about DDD.
The first project I’d like to use it on contains small cameras which are controlled via the GigEVision protocol (over TCP and UDP for the control and stream channels). I think my problem would be the same for any case where we maintain a connection to an external component or more generally we want to link an external component lifecycle to Axon’s lifecycles.

I’d like to have an Aggregate named Camera to which I can send Commands to grab 1 image or start grabbing N images at a certain FPS.

What I’m not sure about is how to manage the connection to an external component in my Aggregate.

  • Should I inject the client to my camera in my Camera Aggregate and consider connecting to it as part of my protocol / business commands? In this case how would I link the camera lifecycle (a camera get disconnected all of a sudden) to the aggregate lifecyle (create a corresponding CameraDisconnectedEvent)?

  • Should the connection be handled in a side car Saga which get the camera client injected, the saga starting on ConnectionRequestedEvent and stopping as soon as we get a connection error from the camera. I would get the same issue of linking the connection lifecycle to the lifecycle of the Saga I think.

  • Am I leaking implementation details in the business layer and should manage the issue an other way?

  • Am I just using the wrong tool for this job and should not try to force it into Axon?

Thank you very much in advance, hope my message and issues make sense.

Best regards,
Antoine

#2

Hi Antoine,

First and foremost what you should do, is ensure the language spoken by the GigEVision protocol by no means transitions over into your other domain.
These two should be separate and remain so, as they cover different concerns.

This brings to light the necessity to have a translation layer of some sort.
More formuly called a context mapping. From a DDD perspective, you would take this even further by talking about an Anti-Corruption Layer.
The name already says it, you add a layer to ensure you are not corrupting your domain logic with that from another domain.
Another useful topic to read up on here would be the notion of a Bounded Context.
I digress though, let’s go back to the problem at hand: where to position this anti-corruption layer.

What is currently unclear to me, is what domain requirements are in place why the connection is required to be maintained all the time when requesting for images.
Is the command you want to send requesting for a live feed? Or just “some” images from a given time frame?
In both scenarios I am not immediately convinced that any of these operations requires the validation through a single Camera aggregate to be honest.

You could still model this in a command and event format, as the messaging paradigm is very helpful to allow clean segregation of concerns.
But given the current description, I am uncertain whether you need DDD’s idea of an Aggregate to model a single Aggregate in.
I might be wrong on this note, but I just don’t know enough about your domain at this stage.

If you want to further the discussion, I’d like to point out that the mailing list will be closed soon.
Instead, we are opening up a different solution under https://discuss.axoniq.io/, so any other questions you might have are best situated there.

That’s my two cents to the situation, hoping this helps!

Cheers,
Steven

#3

Hi Steven,

Thank you very much for taking the time to answer me through a thorough answer.

First and foremost what you should do, is ensure the language spoken by the GigEVision protocol by no means transitions over into your other domain.
These two should be separate and remain so, as they cover different concerns.

I totally agree with you on that, I mentioned GigEVision as an example of a connection that have to be established for my Camera business logic (start streaming, stop streaming, grab one frame) to happen.

You could still model this in a command and event format, as the messaging paradigm is very helpful to allow clean segregation of concerns.
But given the current description, I am uncertain whether you need DDD’s idea of an Aggregate to model a single Aggregate in.
I might be wrong on this note, but I just don’t know enough about your domain at this stage.

What I understand here is that I would have a CQRS-Event driven Camera component outside of my domain logic. Some commands / events of my domain logic would be translated to the Camera component api by the Anti-Corruption Layer (and same on the way back). In this case the Camera component would live outside of Axon framework’s scope and communicate via the Anti-Corruption Layer. Is that right?

If I consider the fact that a camera is streaming or not as part of my domain logic and want to validate the start / stop commands and recover my state if I have to restart my service, then I’d have a Camera aggregate but still have a Camera component behind an Anti-Corruption Layer to do all the GigEVision handling.

I understand what you’re suggesting is that the fact that the fact that connection might be broken or impossible with the camera at the implementation level is not relevant in my domain logic where I only have start / stop streaming logic. Therefore I should either:

  • Be able to start / stop streaming not matter the fact I can start / stop streaming, but maybe not receive images.

  • Have the start streaming handler validating it’s possible via the Anti-Corruption Layer, staying in a “StreamingRequested” state before having a confirmation command through the Anti-Corruption Layer. Have other implementations level errors be translated as well to Camera commands. In this case a loss of connection might be translated to a stop streaming event upstream.

Would that be correct?

If you want to further the discussion, I’d like to point out that the mailing list will be closed soon.
Instead, we are opening up a different solution under https://discuss.axoniq.io/, so any other questions you might have are best situated there.

From what I understand all conversations are entirely exported over there, we can continue this discussion directly over there?

Thank you very much once again.

Antoine

#4

Hi Antoine,

The assumptions you are making based on what I am sharing are indeed correct. :slight_smile:

When it comes to continuation, these user group threads will indeed be carried over to our discuss channel, on the 28th of September.
If it is necessary, we can indeed proceed chatting about your domain over there.

Cheers,
Steven

#5

Thanks a lot!

Antoine