Structures are great for representing value types. Things like dates, ranges, numbers; stuff where equality depends on the value of the object rather than the instance of the object. They’re good for messages and certain other components in a concurrent program, since the copy semantics make some aspects of that sort of design very clean.

But that’s rather in their definition. In practice, they’re used more often as a map to some data on disk, or from some other external source since structs can be made to have rules about how they are laid out and packed in memory. So then instead of reading up a byte array and doing the parsing yourself, you can marshal up the structure all at once, letting the runtime do the error-prone stuff.

In C#, structs are value types, while classes are reference types.
So you use a struct whenever a value type is called for, and a class if a reference type is more handy.

That’s about all there is to it.

My own rule of thumb, it may be wrong:

I’d say a struct is the strong, static typing equivalent of a tuple. Use it when every possible combination of values in the struct is valid and equally reasonable.

On the contrary, classes have a limited set of valid states and have more complex setters and getters, that may need to do validation, too.

In C# you are forced to allocate objects on the heap and reference them with a pointer. Structs allow you to put “objects” on the stack. Allocating a value on the stack rather than a pointer affects checks for equality, garbage collection, and the speed of allocation.

C# mixes in a heap vs stack decision. In C++ you can do the opposite of C# if you like and put a class on the stack and struct on the heap. With C++ it comes down to design choices about polymorphism rather than the memory allocation decision that C# forces on you.