Hi Conrad,
welcome!!! 
EDIT START (PS): There was one really good session on writing reusable code at Unite 2008. It’s not available online, yet - but it will be at some point in time (I would hope by the end of this year or earlier). That’s one thing you’d definitely want to watch.
Also, I found Workflow and Assets Pipeline, a session of Unite 2007 quite helpful and inspiring.
EDIT END
There’s various approaches to scripting in Unity, and I guess every approach has their pros and cons. What I’m doing from the “project organization point of view” is having one folder “Scripts” in my assets folder, and under that folder I have a couple of subfolders which basically resemble namespaces or packages (I prefer viewing those as packages, in the OO or Java sense ).
Unfortunately, for MonoBehaviours, which are subclasses of MonoBehavior and can be attached to game objects (which is how you connect the logic with the game), you cannot use namespaces due to some ugly limitations with Unity. If you search the forums, you should find some discussion on that. Some people use delegation to solve this - so they have something like “MyMonoBehavior” which then delegates the various engine calls (Awake(), Start(), Update() and so on) to classes that do not inherit from MonoBehaviour but implement some own defined interface. I think there’s some issues with that (e.g. when you’re using a lot of RPCs), but it’s definitely worth consideration.
One thing you can also do is have your own library or libraries that you compile e.g. with Visual Studio into assembly DLL(s), and then you can use those from your scripts.
Personally, I really like the way Unity handles scripts as “components” that you can attach to game objects because it gives you a lot of flexibility during development, since the public “properties” are exposed in the inspector. Well, “properties” in this context really means public member variables, which is kind of ugly again. To solve that, I have a convention of never accessing anything lower-case from another one of my classes - so I wrap “real properties” around those public member variables if I want to expose them.
I’ve been through some “iterations” trying various approaches and ended up using a couple of “empty game objects” of which each simply holds one specific manager script (of which I have a couple with different responsibilities). These are also prefabs and act as singletons. The major advantage of this approach is that those objects are “visible” in the editor, which gives you a lot of control. Keep in mind: All settings in the public member variables are persistent and can be set via the inspector within Unity - so you can tweak everything you expose in this way very easily.
The actual game objects (vehicles, level objects and so on) then use those manager-singletons. I also have a few pure C#-classes to have some lightweight data-containers, but in general, anything that does significant logic is a MonoBehavior attached to a game object. One reason for that is that I’m using Unity’s built-in networking a lot, and scripts that have RPCs must be MonoBehaviors attached to game objects.
Well, I guess that’s somewhat of a very broad overview. Hope it helps
Personally, it took me a while to really grasp how to best do things with Unity (and I’m not saying that I fully grasped it, yet ), and in the process, I had my pains and complaints - but in the end, except for some unfortunate limitations (like the namespace-issue), I think it’s a pretty genius approach, even when it seems a bit unusual at first.
Sunny regards,
Jashan