Introduction

In Concept: IT Architecture the concept of viewpoints (views and aspects) were defined, which organizes the models of the system. Another level of organization is also available for the Locations aspect, namely the use of Domains and Zones.

Domains are typically defined once, and may not even show up on the model, except perhaps for the Context Diagram, see Guideline: Business Perspective Views. It usually encompasses the complete system and specifies the policies, laws and other rules that apply along with the authority for these rules.

Zones provide a very useful grouping or classification of networks and all of the elements involved, from routers to servers. Typically this partitioning is defined based upon IT security aspects, such as data sensitivity, survivability, availability etc. Other notions may also be used; whatever is convenient and practical.

Domains 

Domains, as noted, typically encompass the complete system. They may be shown only once, on the Context Diagram for the system (e.g., the "Airline: Manage Passengers" Domain):

It is an environment or context that is defined by security policies, security models, and security architecture, including a set of resources and set of system entities that are authorized to access the resources. A domain is managed by a single Authority, and may contain one or more sub-domains. Different sub-domains are created when security models or policies (and possibly architecture) are significantly different from one domain to the other, or are conflicting. Separate domains provide clearer separation of concerns and ease policy enforcement and system management. Synonyms: security domain or policy domain. Also see: IT Security Reference Model. 

Zones

A Zone (or Security Zone) is subdivision of a Domain with a well-defined boundary that has a common level of protection for all objects within its boundary. Zones may be logical or physical and may be defined at any layer within the architecture, from physical zones (e.g. building / room), to application-level zones (e.g. application-level access controls and protections). Typically, zones are defined at the physical, network, and application layers. A zone can have multiple sub-zones, but can have only one super-zone. Sub-zones inherit their parents’ properties (i.e. Policies that apply to the super-zone apply to the sub-zone). Zones cannot span Domain or Zone boundaries. 

This partitioning helps to address security concerns, but is also a convenient way to deal with complexity through the definition of Zones, which hide complexity, as in the examples below.

This top-level example Locations Model has two Domains: the "Store" Domain for the store-front operating at the "Public" (unclassified) level, and the "Headquarters" Domain operating at the "Company Confidential" level. The "Headquarters" locations has the drill-down decorator () and therefore more detail is available, shown in the diagram below.

There are a number of "Location" modeling elements that have the drill-down decorator, but the diagram below defines more detail for the "Distribute Research" Zone.

As illustrated above, Domains and Zone are typically IT security centric, but may also be used to logically group together portions of the network as desired.