A mesh will usually fall into one of the 3 following categories:
- Procedurally generated
At it's core, a mesh is just a collection of vertices, edges, and faces.
If you want to import an object I would separate it's identity from it's mesh. So if you import a plane into the game, I would have some object called "GameEntity" which is a class that has a property of type mesh. The mesh is nothing more than the collection of vertices, uv coords, and other mesh specific properties.
If you want to procedurally generate a terrain, I would have an object called "Terrain" that inherits from "GameEntity". This would already have the mesh property from it's parent class. Again, you are separating what the object does from it's mesh representation.
Lastly if you have primitives, I would have stored representations of each object which would include it's mesh, but also all of it's identifying information like name etc. So this would fall under the "GameEntity" class as well.
Long story short: in your example you are defining cube as a subobject of mesh. Instead I would define everything under a master object class called "GameEntity" which can include a mesh component. Do remember if you implement this that not all "GameEntity" objects must have a mesh. Especially if you had objects like "Camera" inherit from "GameEntity"
I have "Game Engine Architecture" by Jason Gregory. It's a pretty decent overview of the components needed for a game engine. It has a whole section on the rendering engine, but knowing that there are dependencies on the objects you design for rendering is pretty important so you can extend your codebase later.