Ok, due to the inflexibility on this part - if you are doing this just as a learning experience - step back and walk away right now …
Because if you press forward you may have already noticed that there is nothing but an unrewarding exercise in utter frustration ahead of you - which isn’t going to be worth the effort for the “learning experience”. This has nothing to do the any lack of capability on Elixir’s part but everything with how the existing system has been designed to be irreversibly coupled with it’s initial implementation environment - most likely for the sake of a few shortcuts here and there that likely did not help the overall system design.
It is starting to sound a lot like these messages are simply conveyances for some arbitrary serialized object aggregates that can only work because both the client and the server were originally implemented on the same platform and language that enabled them to share an identical class hierarchy - causing the worst kind of implementation coupling.
Now if for some reason an “unrewarding exercise in utter frustration” is somehow the lesser of two evils, the DDD approach would be to create an anti-corruption-layer. But you would need to understand on a very fundamental non-Elixir or non-C# level what the actual essence of these 1040 “types” of messages actually boils down to - so that you can take that insanity and distill it down to some sanely structured information that you can make some sense out of. You will need this fundamental knowledge to build a “layer” the turns insanity into sanity.
Essentially your project seems to suffer from a problem that also came up in this topic - you cannot simply take an object-oriented solution implementation and start translating that implementation into Elixir - typically a solution redesign is required - not because Elixir isn’t good enough but because sadly many OO implementations let their OO ways leak into aspects where they are at best not beneficial or at worst extremely detrimental.
