Il faut comprendre dans le message de Paul que Moodle est issu d'une stratégie de développement pragmatique, on modélise peu, et réalise rapidement à partir du besoin exprimé par les usagers.
Ceci pourrait amener à un immense globi-boulga comme on peut le voir dans d'autres opensource.
Moodle a su publier très tôt des règles simples de codage, et promouvoir une très bonne modularité qui isole chaque module dans son petit modèle de données local.
Les développeurs n'ont donc jamais éprouvé le besoin de se lancer dans des grandes modélisations ou des cartographies abstraites de la plate-forme. (Il y a pourtant des patterns d'abstration à quelques endroits clefs)
Pour ce qui est de l'usage de l'objet : là encore, on évite le dogme du "tout objet "à la Zend" (ce qui fait des architectures tellement explosées en petites unités qu'elles deviennent indébuggagbles par des stratégies simples. L'objet est utilisé selon une stratégie "ad hoc" : Les objets apparaissent surtout à où il y a de l'extensibilité :
une classe abstraite + des plugins concrets qui dérivent de la classe abstraite (exemple : blocs, format de page, etc.). Cela favorise une bonne réglementation des modèles de plugin, plutôt que des "includes normalisés" qui au final ne sont plus jamais si normalisés que ça.
Faire du tout objet en PHP est un peu ridicule : il n'y a aucune persistance, ni serveur d'application. On s'ennuie à faire des objets pour des durées de vie qui sont celles du déroulé du script/page. Hormis pour la structuration de l'architecture : modularité, extensibilté, dérivabilité, c'est inutile.
J'en ai fourni (des mappings du noyau central de la bdd) quelques uns dans la doc dévelopeur 1.9, mais suis un peu en retard sur Moodle 2 :
http://docs.moodle.org/19/fr/D%C3%A9veloppement:Mod%C3%A8les_de_donn%C3%A9es