If you're thinking something that will have one global league, like pokemon go, league of legends - things where scores area compared - then you need the communications to go client-server only.
There are a bunch of ways this will make it easier, but among them are that your clients can know the address of the server, and with peer to peer it would be virtually impossible to prevent cheating.
If you're thinking of a LAN game sort of thing where a bunch of people set up a game together, play for a bit and close it down, then you could do peer to peer. This introduces a few problems, the body being network related: discovering the other clients and routing. Often discovery is done using UDP and this doesn't cross network boundaries well.
I'd use the minecraft model myself. (Pretty sure the original Doom did similar back in the day).
Basically one machine gets dubbed the server and coordinates objects - location, velocity, creation destruction motivation inventory.
When a client joins they need the address of the server. Minecraft makes it easy for the user to set up a LAN game by telling the person on the server the address to use.
In terms of responsibility, I'd say it goes both ways, but you don't have to agree. Depending on your protocol, some things will be easier to implement.
If you can have open sockets/long connections then both ways will be really efficient. Client tells server when an event happens - a purchase, a death, initiating a ballistic path. Server then tells all of the clients who then update their local data.
You'd probably want to chase this option if you're doing real time action.
It might be simpler though to have your clients polling the server for state change. Your comms code might be simpler but you'd have to think real hard about minimizing the amount of data you transmit.
For same / different classes - it depends. I'd start with the same. At some stage you'll find data that is only needed by the server or the client and you'll have to decide whether to have it on both anyway (which would make switching a local game to multiplayer and back easier ) or separate them (which gives you more code to manage but may improve security). I'd leave that decision as late as possible.