When building Active Directory, there is really no right or wrong way to set up the various Active Directory elements, although some implementations are certainly more efficient than others. The attached drawing represents a fairly typical Active Directory implementation for a medium-sized organization. Although my sample probably won't fit your organization's needs exactly, you can use it as a starting point. One thing about Active Directory is that it's very flexible. If your initial design doesn't meet your needs, you can always move things around.
What's in it?
In the drawing, I am actually representing two different forests. In an Active Directory environment, a forest can contain multiple domains and usually exists at the organizational level. For example, a medium-sized company would probably have one forest. That forest would encompass all of the company's domains. There is a built-in transitive trust relationship between each domain in the forest. For example, in my drawing, there is a two-way trust between Domain 1 and Domain 2. There is also a two-way trust between Domain 2 and Domain 3. Because these trusts are transitive in nature, it means that there is an implied two-way trust between Domain 1 and Domain 3. To put it simply, in a forest, every domain trusts every other domain.
Additional forests and trusts
You'll also notice a second forest in the drawing. The reason is that there are situations where your organization may not use a single forest. For example, if a domain is not completely within your control or you have an untrusted Administrator over a domain, you might place that domain in a separate forest.
Notice that there is a trust link between Domain 4 and Domain 3. This trust link is set up at the domain level and is non-transitive in nature. This means that even though Domain 3 trusts Domain 4, Domains 1 and 2 don't trust Domain 4 unless a trust between them and Domain 4 is explicitly created. Trusts between domains in external forests can be one-way or two-way trusts.
Inter-forest trusts are also common in business-to-business (B2B) relationships. For example, suppose that one company was a manufacturer and another company was a reseller. The reseller may need to print copies of orders on one of the manufacturer's printers. To do this, a one-way trust could be established, and the users at the reseller company could be given rights to the manufacturing company's printer.
Domain controllers, computers, and users
Beneath each domain in the drawing are containers for Domain Controllers, Computers, and Users. These are built-in containers that Windows creates in every domain by default. The Domain Controllers container holds all of the domain controllers for that domain. The Computers Container holds member servers and workstations for the domain. The Users container holds the domain's user accounts and security groups.
Windows allows you to keep things nice and organized by providing you with the default containers, but this doesn't mean that you have to follow this organizational structure 100%. Notice that in Forest B there is a fourth container called OU. An OU is an organizational unit.
An OU is basically a container that the Administrator creates. An OU can contain users, groups, and computers. The idea behind creating an OU is that you can group objects so that they can be managed by a specific group.
For example, I might create an OU for the Finance department and place all of the users and computers belonging to Finance into this OU. I could then delegate control of the OU to someone in that department so that they could administer themselves without having administrative control over anything else.
There is one last structure in this diagram that I would like to talk about. You might have noticed the Site Link Bridge shown in Forest B. Sites are an Active Directory structure that are used to ease replication traffic over slow WAN links. Suppose for a moment that, even though Forest B only contains one domain, the domain spans two buildings, connected by a slow WAN link.
Normally, when an update is made to a domain controller, the updates are replicated to every other domain controller in the domain. If there were ten domain controllers in the alternate facility, then this replication information would pass across the WAN link ten different times, once for each domain controller. This is where a site link comes in. By creating a site, you are basically telling Active Directory which side of the WAN link each domain controller exists on. You can then designate one domain controller on each side of the site link as a bridgehead server.
A bridgehead server is responsible for sending and receiving Active Directory updates on behalf of a site. For example, if an update was made to Active Directory, the local domain controllers would be updated immediately. The local bridgehead would receive the update and pass the update across the WAN link to the remote bridgehead server. The remote bridgehead server would then be responsible for distributing the update to all of the domain controllers in the remote site.