This section is currently under construction. Please feel free to add any insights you may have into the structure of the Source engine that you would like to share with the community.
The Source engine is designed in an extraordinarily modular fashion. This was done to allow both easy updating, and obfuscation of proprietary code. This guide will not show you how to access these off-limits areas, but it will give you an outline of what these different modules are, how they interact, and how to best extend them.
The Source Engine makes use of a number of individual subsystems with a very standardized structure. Each subsystem defines an abstract interface in a .h file, while typically implementing it and creating a global variable in a .cpp file. Through macros or by simply adding it to the client/server's initialization function, that global variable is added to the list of active systems. Once hooked up, the existing hooks take care of initialization, shutdown, and calling the appropriate update functions as necessary.
There are two different system hook types used. First, and most simply, IAppSystem is used for client systems. <Guesswork>This doesn't mean they can't be referenced in the server dll as well, however there is no information transmitted between the client and the server</Guesswork>. It offers only the hooks necessary for initializing a subsystem with possible references to other subsystems, and shutting down at the appropriate time. The file, material, and physics systems all derive from this interface.
Second is IGameSystem. A comparatively more complex interface, this is designed for systems which need to have update functions called and may be need to be synced between client and server. Aside from the standard initilization and shutdown hooks, it also offers hooks that are called on a number of events including map load, save/restore, pre/post render, and an update function with the frame time passed in.
Valve's STL, console commands/variables and more; see Tier1.