I am new to the world of server configurations and am having a hard time coming to grasps what a domain is especially in an internal environment. For example I have read and been told the best naming convention to use for an internal domain is domain_name.local. However I have no idea of the purpose of having a domain and what it does?
The second question I have is if I have a registered domain name e.g. example.com which points to a website, how does using the domain name example.com affect me using same name when setting up a web server and mail server?
I am unsure if the same terminology carries across Windows and Linux however if it does, I would like to know how this relates to Linux.
Domains are handy things, since it allows you a single namespace to locate resources. Even internally, this is quite useful. Most companies only have a few externally accessible addresses and quite a few more internal ones. Using a subdomain ("winserv023.hosting-nyc-usa.example.com") under your publicly visible domain ("example.com") makes it easy to set up and not conflict with anything else out there on the internet.
Using an arbitrary root ("winserv023.companyname") has its own problems, even if it'll never ever be visible to the world. With the expected explosion in top-level-domains in coming years, it is not impossible that "companyname." could be a perfectly valid top-level domain.
DNS domains are completely different than Windows Active Directory Domains, though AD domains do use DNS for resource location. DNS domains function the same on both Linux and Windows and follow very similar terminology. Windows DNS and Linux BIND DNS have slightly different terminology usage in their documentation but they both do the same thing in the end.
Imagine you are in charge of a bunch of computers. Let's also imagine that you are tired of just referring to them by their IP addresses. Let's say you've given them cool names instead. And now you would like some way for every machine on your network to be able to find each other just by using their names. So you go and setup a DNS server, which can be queried for information about these names and who they belong to.
DNS is hierarchical, so at the top (or the root of the tree) you have the root DNS servers (represented by '.'), then you have top-level domains (.org, .com, and so on), then domains, and subdomains, and so on ad infinitum. So you need to group your names into a container. This container is your domain namespace. For example let's say your domain name is middleearth and your workstation is frodo (frodo.middleearth) and your server is gandalf (gandalf.middlearth).
The big difference between an "internal domain" and an "external domain" is who is able to query your DNS server and thus learn everything there is know about your domain. If you've setup the middleearth domain because YOU and your organization just got tired of using IP addresses to refer to all your machines (see @JamesHannah answer for why this is annoying), then you DO NOT want the public/internet/world talking to your DNS server; so outside of your network no one even knows your domain "exists". Inside your network all your machines know that the mail server is gondor.middlearth and that your DNS server knows where to find it.
An "external domain" is one you want the public/internet/world learning about... like say your website. So you buy a domainname from a provider, they make the records changes (or you do it yourself if your DNS server is publically accessible), and now everyone can find your domain. If you already own example.org you can again either through whomever does your DNS services or if you provide them yourself, add a mail server called mail.example.org (using an MX record), or really anything that you want to be part of that namespace.
And as noted by sysadmin1138, this concept is part of but not at all inclusive of what makes up an Windows Active Directory Domain.
In my opinion this is really a question about DNS. I've always liked Technet's article here, but you may find it overly long. It's well worth understanding DNS as a system administrator. It's the glue that pretty much holds the internet together (well, that and perl...).
Assuming you understand how domains are used on the Internet, it's easiest to think of local domains as an extension of that. These days DNS is the primary means of identifying hosts on a network. All DNS entries must reside within a domain. It follows therefore that a domain is required.
As an example, all the computers on our company network have DNS entries in the company's internal domain, just as our public resources have DNS entries in our public domain.
So, a domain is basically just a way to refer to a resource (server/group of servers) by a name instead of an IP address.
Referring to a resource by IP address is bad for obvious reasons, you're not able to change the IP address of the resource without updating all your configuration that refers to it. If you're using DNS or some kind of zeroconf domain name system (e.g Bonjour), then you can just update the mapping between domain-name and IP address to point to a new physical resource.
Obviously whether you use a private domain or public domain is like using a private or public IP address. Private domains e.g "mailserver.local" or "pdns.mycorp" means that the resources will only be addressable internally. If you want something to be publically addressable, or don't want to roll out your private DNS infrastructure, you'll need to buy and use a public domain name, something ending .com or .net or whatever.
It's basically up to you, you need to choose something which is consistent and make your DNS service reliable. It's platform agnostic as well, the only thing you'll need to worry about is what DNS server/method you use. I believe Windows deployments tend to mostly use ActiveDirectory as a DNS server, since you'd need to have one in a Windows domain anyway.
On *nix, the traditional, venerable choice would be Bind, but other DNS servers are available.