If you have specific questions about how Moodle works, please ask them here.
One of the more interesting things that has been written about how Moodle works is Pedagogy. Particularly the "Social Constructionism as a Referent" section. Point 4. there is relevant. To explain something to someone, you need to know where they are coming from. What they already know. It is probably futile to expect a single Moodle architecture document to satisfy everyone.
On the other hand, that is not an excuse not to try to explain the basic bits that everyone wants to know. What should such a document say. Let's try drafting something: (where it makes a difference - not many places - I describe Moodle 2.0)
Overview of a Moodle installation
Moodle is a Learning Management System, Course Management System, or Virtual Learning Environment, depending on which term you prefer. It goal is to give teachers and students the tools they need to teach and learn. Although it comes from a background of Social Constructionist pedagogy, it can be used to support any style of teaching and learning.
Moodle is a web application written in PHP. Moodle is open source. Copyright is owned by individual contributors, not assigned to a single entity, although the company Moodle Pty Ltd in Perth Australia, owned by Moodle's founder Martin Dougiamas, manages the project.
A Moodle installation comprises the Moodle executing in a PHP-capable web server; a database managed by MySQL, PostgreSQL, Microsoft SQL Server, or Oracle; and a file store for uploaded and generated files (the moodledata folder).
All three parts can run on a single server, or they can be separated with many load-balanced web-servers, a database cluster, and a file-server. Or anywhere between those extremes.
Moodle as a modular system
Like many successful open source systems, the moodle structured as a core system, surrounded by numerous plugins to provide specific functionality.
Plugins in Moodle are of specific types. That is, and authentication plugin and an activity module will communicate with Moodle core using very different APIs each specifically tailored to the type of functionality the plugin will provide. Functionality common to all plugins (installation, upgrade, permissions, configuration, ...) are, however, handled consistently across all plugin types.
The standard Moodle distribution includes Moodle core and a number of plugins of each type, so that out of the box, Moodle provides a lot of functionality. By installing and removing plugins, a particular Moodle installation can be adapted for a particular purpose.
Moodle core provides the infrastructure necessary to build an LMS by supporting the following concepts.
A course, which is a sequence of activities organised into sections. Courses are organised into a hierarchical set of categories within a Moodle site.
Users, profile, my moodle ... (sorry, can't be bothered to explain all this now, will just make notes.)
Groups and Cohorts ...
Contexts, roles, capabilities, and permissions, ...
Activity and course completion ...
Navigation, settings and configuration ...
Installation, upgrade ...
Logs, reporting, statistics ...
The most important plugin types
Activities (and resources) - the individual items that make up a course. The main tools for teaching and learning. For example forum, wiki, quiz, .... Activities are by far the largest type of plugin in terms of amount of code. I forum or wiki system could be a software project in its own right.
Blocks - small bits of functionality that can be added to the sides (normally) of other pages. Many blocks provide views of data that is available elsewhere, allowign that information to be displayed on the course page, for example.
Themes - The overall visual style of a Moodle site, or of a particular course, or all courses in a category, can be changed by selecting a different theme.
Language packs - Moodle is internationalised, and you can get language packs for many languages. http://download.moodle.org/langpack/2.0/. (Individual user-interface strings can be customised in any Moodle installation from within the admin screens.)
Course formats - Controls how the structure of the course, a sequence of activities grouped into sections, is presented to the users.
Authentication plugins - Controls how users log in. Moodle can manage usernames and passwords itself, or use those stored in LDAP or another database. Alternatively, Moodle can use a number of single-sign-on schemes.
Enrolment plugins - Controls which users are enroled in which courses. Again this can be by synchronising with another system, perhaps a student information system, or it can be tracked internally by Moodle.
Repository plugins - Ways for users to get content (files) into Moodle. Either by uploading from their hard drive, or by getting the file from another location on the Internet, perhaps Drop Box, Google Docs, or Flickr.
There are many more types of plugins (more than 30 at the last count). These include text filters, question types, gradebook reports, admin reports, course reports, plagiarism detection services and web service protocols.
How Moodle code is organised
Moodle follows mostly a transaction script approach. That is, suppose you are looking a a Forum. The URL will be .../mod/forum/view.php, and that is the PHP script that will be in overall control of the display of that page.
However, behind that basic transaction script approach, a lot of the core functionality has be refactored out into libraries (mostly in the .../lib folder). This provides something of a domain model. (However, the Moodle project started before PHP was capable of supporting object-oriented code, so don't expect an object-oriented domain model.)
HTML is mainly output through renderer classes. These allow different plugins to generate a consistent user-interface, which the themes can control. So, for example, there is an $OUTPUT->box($contents); method.
The Moodle database
The Moodle database has a database that comprises many tables (more than 250) because the whole database is an aggregate of the core tables and the tables belonging to each plugin. However, this large database can be understood because the tables for one particular plugin typically only link to each other, and a few core tables.
The Moodle database structure is defined in install.xml files (inside the DB folder in each plugin, and lib/db for Moodle core). To see those definitions in human-readable form, you can go to Admin -> Development -> XMLDB editor, and click on the [Doc] link.
OK, how is that for a first draft. It is longer than I was hoping, What could be missed out? Also, what is missing.