I started this project a week ago but I still cant find a good way to store my cards data and to instantiate each card. I ended up with the following uml diagram:
Well since you have ScriptableObject definition of a card, you can easily and quickly get all of them in one line:
// You can cache this in a Manager/Singleton "CardsManager" and be done with it.
var allCards = Resources.LoadAll<CardScriptableObject>("Cards");
Just make sure to store all your Cards SO assets in a folder called “Resources\Cards”.
The only advice I can give you is: don’t overcomplicate/overengineer things (eg. store every data you need for a card in a single ScriptableObject, use as much Unity tools and techniques as possible…) don’t try to follow any “Principle” or “Designs” like SOLID, DRY… blindly (also don’t follow the YouTubers religiously preaching for them, 99.99% of them never released a real game) since game dev is quite different than all other type of programming…
Just remember the #1 rule in (indie) game dev: Make it work first, refactor last (and only if it’s really needed)
I really struggle with overanalysing/overengineering code and software in general. And yes, SOLID principles are killing me. I am at my seccond year of software engineering and I would like to implement in unity what I learnt but it is really hard to follow the principles every time. I really like to make my code always as “modular” as possible so it is scallable and all that but yeah it is making programming for unity a nightmare. About the youtubers, I am 100% with you. Thank you for your help though 
.
My solution:
Forget all about diagramming classes and start working on a card game. If you’ve used Unity before you should be able to have a deck of arbitrary cards dealing and sliding around a table in under a day. Think of how successful you will feel when you have this working.
Now… stop. Stare at it. Think of your business use case, what these cards must display and show, what the cards must do, what user interaction must happen with them, how the cards must move.
At this point it might help you to go try a few tutorials (OUTSIDE of your project) to see how others did it. Be sure to actually DO the tutorials, not just watch them. You need to get a feeling for what is happening.
And from this begin to loop back into your initial gamejam card-moving code and see where things could / should live, and begin to add one step at a time to move closer to your game.
Can this cause mass chaos in your programs? YES! Can you fix mass chaos? YES! Look at 100% of your software as “the way it stands right now but I could completely destroy any of it at any time I want and remake it.” This process is broadly called refactoring and is a CRITICAL part of iterative development, which in turn is a CRITICAL part of all gamedev work, since gamedev is easily as much an art as it is an engineered science.
Don’t be afraid to throw it all out and start afresh at any point. Don’t let bad choices “logjam” your project.