I tried to put every subdirectory of InnoDB codebase into a chart that would explain some of relations between subsystems and modules inside the source. This is what I got (click to enlarge):
Update: Check Vadim’s diagram for a more operational view of InnoDB
Another update: There’s a vector PDF version
domas mituzas 
I’m going to fire up the plotter.
You forgot to edit the relevant article: http://en.wikipedia.org/wiki/InnoDB !
I asked this question to several people but no one knew. Why is it that, in InnoDB, there are tons of files named
foo/foo0foo.c?btr/btr0btr.c
buf/buf0buf.c
data/data0data.c
dict/dict0dict.c
dyn/dyn0dyn.c
eval/eval0eval.c
fil/fil0fil.c
fsp/fsp0fsp.c
fut/fut0fut.c
ha/ha0ha.c
ibuf/ibuf0ibuf.c
lock/lock0lock.c
log/log0log.c
mem/mem0mem.c
mtr/mtr0mtr.c
page/page0page.c
pars/pars0pars.c
que/que0que.c
read/read0read.c
row/row0row.c
srv/srv0srv.c
sync/sync0sync.c
trx/trx0trx.c
ut/ut0ut.c
0 is separator, module has to be in file name so that error messages (and other internal structures) that have filename:number tell what module the problem is, and sometimes there’s just one module, so instead of calling the file foo0main Heikki called it foo0foo ;-)
Not that much magic, I guess.
Compiler limits from back in the day — function names had to be unique in their first 8 chars. Read Ingres source to see the impact of this, or get a job at Oracle and read their source.