Data structure of IFC-files I know OBJ-files essentially are one or more lists of n-tuples containing information about the location of vertices, texture and normals. However, I am not sure how this is structured in an IFC-file. 

However, whenever I look for the data structure of IFC-files, I find information regarding the hierarchy of elements in IFC, but I cannot find information regarding how the geometry is saved. Also, how is this related to the hierarchy of entities in the model?

What should I learn to understand this?
You need to learn and understand STEP data exchange format (ISO 10303-21) which is the fundamental exchange format which the IFC schema is built on top of. This is no easy feat though, especially when comparing to a file format such as OBJ. OBJ files are designed to define geometry (and other information via associated MTL) and so are optimised for this purpose. IFC on the other hand, is designed to exchange many aspects of AEC including building, services, structural, furnishings, energy model etc and so is far more complex with the geometry definitions being only a subset of the information supplied in an IFC. It would be easier to use an existing IFC library to do this, and even then, an understanding of the structure of the IFC entities and their hierarchy is still required to traverse the relationships (inverse attributes) between the object definitions in an IFC file in order to reconstruct the desired geometry.

OBJ files explicitly define the vertices, normals and faces that represent a mesh, however while there are IFC entities which can represent meshes in a similar fashion (namely IfcConnectedFaceSet), most geometry defined in an IFC file should be considered more like a series of instructions/commands to recreate the geometry. For this reason you would also require a geometry library (one which can do things like extrusions, Boolean/CSG operations, curves, NURBS etc). For example, one of the main things that is represented in many IFC files would be the walls, doors, windows etc of a building, and while these could be represented as explicit tessellated data or breps, in my experience these tend to be represented as an IfcExtrudedAreaSolid (https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ifcgeometricmodelresource/lexical/ifcextrudedareasolid.htm) which supplies the direction and length to extrude a path/outline curve (the curve being defined by an IfcProfileDef which is an attribute of IfcExtrudedAreaSolid, https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ifcprofileresource/lexical/ifcprofiledef.htm). This gets even more complicated when there is an opening (i.e window recess or door opening in the wall) which again is related (through an inverse attribute) to the geometry representing the opening to be removed through a geometric Boolean operation (CSG). As you can see it starts to get complicated fairly quickly and isn't just a case of reading in raw vertices, normals and faces etc.

All geometry in an IFC file is defined by objects which are sub types of IfcRepresentationItem (http://dcom.arch.gatech.edu/aci/cic/schema/ifcgeometryresource/lexical/ifcrepresentationitem.htm) and so that would be the place to start to understand what types of geometry definitions are used by IFC. Other items within the model (namely furnishings) are far more likely to be represented by raw tessellated data (IfcFacetedBrep, https://standards.buildingsmart.org/IFC/RELEASE/IFC4_1/FINAL/HTML/schema/ifcgeometricmodelresource/lexical/ifcfacetedbrep.htm) which is geometry that would be more familiar to you, and there is a chance you can isolate these definitions within in an IFC file and concentrate on processing that (you would still need to understand STEP format, namely the inverse attributes involved, in order to faithfully generate the mesh geometry). Also this geometry could be either explicitly located (in world space), but in many cases is also positioned through IfcPlacements (https://standards.buildingsmart.org/IFC/RELEASE/IFC2x3/TC1/HTML/ifcgeometryresource/lexical/ifcaxis2placement3d.htm) locally, so you need to build up the hierarchy of transformations based on these definitions.

In short, if you wanted to RYO IFC parser to grab geometry, it would be a steep learning curve and require you to understand many other concepts of STEP/IFC outside just knowing the geometry types and transforms. Easier to use an IFC library coupled with a geometry library (although many IFC libs do come with geometry libs to do this for you), but even then, depending on the lib used, you may need to have a basic understanding of the building hierarchy involved in order to correctly place and reconstruct much of the geometry.

Also note, while many of the geometry concepts remain the same through the various versions of IFC (IFc2x3, IFC4, IFC4 ADD1 etc), in some cases there are subtle differences in the schema in relation to geometry object definitions. However, much of the version difference in IFC is do to with the building hierarchy, and associated information for the various disciplines in AEC.