Do I create a country class that contains a bunch of towns?
Do the towns contain a lot building class, most contain classes of people?
Do I make a path finding class that the player can access to get around?
Everything you have suggested above seems reasonable. It may not be the best way for you in the long run, but that's fine. It obviously makes sense to you know since it's the organizational model that first came to you. It's important that you take that and begin an implementation from it. It will both get you started, getting you over this initial "design paralysis" that often plagues developers at the beginning of a task, and (if it proves to be flawed in some way) teach you a thing or two about the pros and cons of that particular approach to design.
You've naturally taken the concepts in your head and grouped them into code according to some simple rules:
- Does this concept differ significantly in behavior or in data from other objects I already have? (Countries and people share very little, if any, meaningful data or behavior, so they should be represented by distinct types in-game).
- Will I even need to manipulate this concept in the code in a significant fashion (if your game deals with individual people, you may need that
Person class, but if the game only cares about them in the aggregate, as in earlier versions of SimCity, you may not need that type nor instances of that type to create a 1:1 mapping of a town's population.
int populationCount may be enough).
- Does this concept require state? If so it should be encapsulated somehow that allows me to store this state (a class) rather than a bunch of free functions. (A pathfinding implementation doesn't have an analogous real-world object, but it does require keeping track of data such as which nodes in the map it has already considered, and that is better done through a class than by storing it in a bunch of hidden globals and making freestanding functions).
While simple, answering those questions can benefit you a great deal when trying to decide if and how to transform a mental concept into source code. You may also want to read up on the SOLID principles of object-oriented design.
Note that the suggestion of an entity/component system made in the comments is also a valid approach, though I would eschew it here unless you re-scope your project to be smaller (simply because taking on two new, large challenges in one project may be too daunting and may dilute the educational benefit you would otherwise receive from focusing only on one). In a component-oriented model, the "type" in the questions above becomes more implicit: not the concrete type in code, but the implicit type defined by the collection of components that form an entity. The same guiding principles can apply.