File Notes:

Fracture Core

Interface to Voro++ via self-written C-interface (in voro++ folder) and FILE descriptor which passes raw data back from voro++ (voro++ design, not mine)
Important DNA structs: FracMesh (contains Shards), Shard (contains verts, polys, loops and customdata), those interface via readfile.c / writefile.c (Blenloader) to storage subsystem
BKE_fracture.h (allows Modifier and Rigidbody subsystem to access fracture core)

containts the 2 actual main fracture methods (boolean and bisect)
Interface to Carve Wrapper (NewBooleanDerivedMesh())
Interface to Bisect Operator (via temp bmesh, is converted only once at fracture time, so no simulation performance hit),

Interface to Rigidbody subsystem (many changes, adaption of most functions for modifier and mesh islands), also in Header BKE_rigidbody.h,
Adaption for multiple rigidbodies in 1 object, world has linear_index_map, linear_offset_map

the modifier itself, references FracMesh, Bmesh and Derivedmesh, able to fracture meshes and texts / curves (does clean up of derivedmesh), contains shards (storage interface) and meshislands (sim interface)
rigidbody sim moves verts of meshislands, which reference the visual derivedmesh and manipulate it this way, modifier also stores constraints (will be regenerated each time the file is loaded, no storage, since generations is very fast and storage made more trouble than being useful)

RNA: rna_modifier.c,
DNA: DNA_modifier.h, (struct definitions, needs urgent cleanup, WILL break old builds, very clumsy still (better use flag system or bitmap system but not so many ints....)
general modifier setup / registration stuff (different files)
wm_jobs.c: Threaded execute of fracture, optional, might be removed again)
picking attempts in drawing code, remainders need to be removed in any case
python: GUI, properties_physics_fracture.py

the modifier serves as in-memory storage for everything fracture related basically....
visual (cached) mesh, the meshislands, the shards and the pointcloud are all part of the modifier struct itself in the DNA
so everything is stored with the object
the DNA structs ensure correct storage in blend file too via writefile.c and loading via readfile.c, at the time the modifier is stored or loaded

to access data from the modifier, which for example is done by the rigidbodysim, you have to access the objects having a Fracture Modifier in their modifier stack
then you can access the meshislands by iterating thru the according linked list
in the rigidbodysim the meshislands are accessed this way and their verts are moved according to rigidbody movement, which affects the visual derivedmesh directly and lets the object break apart visually