You don't want a multi-domain environment. You only use a multi-domain environment when you have to (differing password policies for different users in a Windows 2003 environment, using the domain as a boundary of replication for two or more very large environments). A single domain environment is the way to go.
You're right to put at least one DC at each physical location. Be sure you setup AD's "Site" and "Subnet" configuration so that AD can make intelligent replication decisions and (more importantly) client computers can make intelligent decisions about which DC they talk to during logon. Both DCs should be ticked as "Global Catalog" servers, and should provide DNS services for PCs in their location. (You should specify the far-end DC as a secondary DNS server for PCs, but you'd like them to talk to the DC in their location first.)
The organization of users, computers, groups, and other objects into OUs within your Active Directory (AD) is based on two criteria:
- Delegation of control of administrative tasks within AD
- Application of Group Policy
As a tertiary concern, you might organize objects in AD to be visually easy to locate, but that is strictly an aesthetic concern.
Delegation of control relates to the modification of the default permissions in AD to allow other users the ability to perform adminsitrative tasks. Imagine a scenario where you have an off-site branch office, and an "IT power user" in that office who wants to perform password resets for users who forget their password in her office.
By delegating control to her (via placing her in a group and delegating control to the group) to reset passwords only on the OU where the user account objects representing users in her office are located (possibly in sub-OUs-- the delegation inherits to sub-OUs by default) you grant her the ability to reset passwords only for those users.
In a small organization there might not be a large amount of delegation of control, but it's something you should at least think about when "whiteboarding" your potential configuration.
Group policy is typically applied to users or computers by linking the group policy objects to OUs. (It's possible to use group policy without any OUs at all but it's a big pain and not a realistic deployment strategy.) If you needed to install an application via "Software Installation Policy" onto all PCs in the Accounting department, for example, having the PCs organized into OUs representing departments would give you an easy way to target a GPO at all those PCs.
The application of group policy can be controlled via other means (group membership of the user or computer, WMI filtering, IP subnet by way of group policy objects linked at "Site" objects), whereas delegation of control can only work on an OU basis. As such, delegation of control is your first overriding design concern (i.e. make sure the proposed OU layout works for your desired delegation of control strategy), and group policy application (which is more fluid) is a secondary concern.
You might do well to have someone familiar with Active Directory sit down with you for a couple of hours and ask you some questions about how you want to use your AD to come up with a proposed design. It sounds like a pretty simple environmnet and OU hierarchies are easy to re-engineer down the road, but a good AD consultant might give you some excellent ideas that, as you grow, allow you to minimize administrsative expense and streamline delivery of functionality to users.
Edit:
I would take some issue with the statement in your comment re: "the OU hierarchy should replicate the structure of my organisation." The OU hierarchy should support your desired delegation of control and group policy application strategies. If it happens to appear similiar to your "org chart" or some other organizational diagram, so be it. AD isn't an "org chart", though, and you should't assume that the OU hierarchy is going to end up looking anything like any existing organizational diagram.
Security groups are used to grant permissions to resources like shared folders. (You can name individual users in permissions too, but you shouldn't except for edge cases like home directories.) OUs are not "security principals"-- i.e. they don't have a security identifier (SID) associated with them, and therefore cannot be named in permissions.
The AD OU hierarchy is used for controlling group policy application.
The permissions set on the OU hierarchy (and, the structure of the hierarchy underneath those permissions) control the delegation of administrative duties in Active Directory.
Sometimes it feels like duplication to have to create, say, an "Accounting" OU and an "Accounting" security group. Unfortunately, that's the way the product was designed. I can't say that I've experienced that type of situation, though, in many cases.
What gets a bit mind-bending is the idea that a security group is an AD object, and therefore can have its permissions changed to allow an arbitrary set of users control the membership of the group. That group could, in turn, be used to control other types of access (say, permissions to shared folders, or permissions to perform additional administrative tasks in AD). The most easy to grasp group of this nature is "Domain Admins". Delegating someone rights to control the membership of the "Domain Admins" group could (either purposefully or inadvertantly) grant that delegated administrator the right to elevate someone (possibly themselves) to being a "Domain Admin".
Basically, delegation of control over the membership of security groups needs to be well thought-out at design-time. You can do some really powerful and interesting stuff with it, but you need to think it through.
