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:

1. Decentralized administration

2. Geographic limitations: slow or unreliable links or great geographical distances separate parts of your company.

3. Unique DNS namespace considerations.

4. 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:

1. Parent domain: companyalpha.sanjose.internal

2. Sub-domain: companyalpha.reno.internal

3. Sub-domain: companyalpha.la.internal

4. Sub-domain: