Interfaces as components and 'orphan implementation components' about dotnet HOT 8 CLOSED

Am I the only one with this case? 😅

from dotnet.

Declaring components as interfaces shouldn't be a problem ... but what do you mean by "Component Class -- serves -> Interface Component"?

from dotnet.

Hi Simon, thanks for your response.
There's no problem declaring components as interfaces. The issue that I have is for the components that extends from the interfaces and they are used dynamically.
For example I declare a variable as an interface and it could be different components depending on each implementation of the interface.
I don't know how to show in the diagram that the mentioned variable could have different implementations.
Regards.

from dotnet.

So you have multiple implementations of a component interface?

from dotnet.

Yes, I do.
If I use any hardware device for example, I have an interface to define the methods that I will use in my software but each device have their own SDK so I extend the interface to adapt each SDK to my software. And then I load each device using reflection.

from dotnet.

You may need to write your own component finder strategy implementation in that case, as there's no easy/general way to model that situation I'm afraid. If we forget Structurizr for a minute, how would you draw the component diagram manually on a whiteboard? Would you draw one component per implementation, or a single component that represents all possible implementations? Once you understand this, you can then figure out how to represent this using the client library. One option might be to exclude those components from the component scan, and manually specify them instead. Does that help?

from dotnet.

I would like to show that my variable declared as an interface could have several implementations.
Maybe a new annotation could be created to declare what implemented classes could be that variable.
Something like that:

[UsesComponent("Different behaviour based on the consumed workflow")]
[PossibleComponents(WorkflowOne, WorkflowTwo)]
public IWorkflow CurrentWorkflow { get; private set; }

Where IWorkflow is the interface and WorkflowOne and WorkflowTwo are the classes that extend the interface and could be loaded dynamically.
What do you think?

from dotnet.

Creating your own annotations and a custom component finder strategy is certainly possible, and relatively straightforward. I'm still interested in your thoughts on how you would draw a component diagram (on a whiteboard) to represent this. Also, what tooling are you using to create the diagrams? This might be one of those situations where using a UML class diagram is the best way to show the multiple implementations, rather than the C4 model.

from dotnet.