Creating a Domain Model
Creating A Domain Model
TJ Trent
POS/421
December 10, 2012
Jeff Rugg
Creating a Domain Model
Company Alpha is headquarter in San Jose, California with five branch offices located in Los Angeles, Reno, Portland, San Diego, Seattle, and Portland. Currently each office uses two subnets except for San Jose. The San Jose office uses a single subnet.
Recommended Domain Model
Domain models identify the relationships of the entities within the scope of the domain. According to Morimoto, Noel, Droubi, Mistry, and Amaris (2010) when designing domain structures start simple and expand only if necessary. Based upon location of Company Alpha’s offices I would recommend a multiple domain model.
Multiple Domain Model
The multiple domain model allows multiple domains within a single forest. Multiple domains are warranted when the following needs are identified:
Decentralized administration
Geographic limitations: slow or unreliable links or great geographical distances separate parts of your company.
Unique DNS namespace considerations.
Enhanced security concerns.
Two-way transitive trusts exist by default between sub-domains. Resource access is not automatically granted to members of other domains. Resource access rights must be explicitly granted through the use of groups. Company Alpha’s geographical dispersion warrants the use of the multiple domain model. Using a multiple domain model reduces potential congestion over WAN links and reduces the potential for latency.
DNS Namespace
Internal domain namespaces are not published on the Internet. Internal namespaces, therefore, do not have to follow a specific naming convention. Company Alpha does not have an Internet presence although they require Internet access. The following Internal domain namespace is recommended:
Parent domain: companyalpha.sanjose.internal
Sub-domain: companyalpha.reno.internal
Sub-domain: companyalpha.la.internal
Sub-domain: