Dealing with overlapping contexts and concerns is arguably at the core of enterprise architecture remit; it’s also a challenging one as enterprise architects must ensure the autonomy of business units decision-making without impairing the consistency and sustainability of systems. That objective puts domains at the top of the enterprise architecture toolbox.
Types & Instances
Domains are symbolic containers introduced to manage sets of representations bound together by business or technical dependencies. As far as enterprise architecture is concerned, domains should be aligned with organizational units as to ensure clearly defined responsibilities. On that account four basic categories can be identified, depending on focus:
- Business objects, e.g., Customers, Providers, Inventories; templates are tied to entities.
- Business applications, e.g., Purchases, Kitchen; templates are tied to use cases.
- System functions, e.g., Authentication; templates are tied to services.
- Enterprise governance and support activities, e.g., Accounting, Human resources
Templates (≈) can be introduced to standardise the description of these categories, for example: application domains anchored to use cases, object domains to entities, and system domains to services.
Templates (≈) Templates are generic types introduced to manage inherited aspects independently of context of use. Profiles are for descriptive models, patterns for prescriptive ones.
While domains in ontologies are represented as instances of symbolic containers, enterprise architects can introduce types to implement industry standards or enterprise methods, for example regulations. Such types can be marked as templates (≈) to avoid confusion with nondescript inheritance.
The contents of actual domains (instances) can then be defined in terms of included instances (e.g., customers domain) or types (e.g., Customer, DinerReservation).
Reuse & Sharing of Domains
Domains serve two main purposes:
- With regard to enterprise organization, they ensure that visibility and accesses are aligned with roles and responsibilities.
- With regard to supporting systems, they are used to implement address spaces, ensuring the autonomy and modularity of implementations.
Considering a simplified case of an enterprise domain (a), with domain instances for customers (b) and reservations (c); the enterprise domain also includes an anchor (#) entity for the management of parties identified in environment (d).
The customers domain (an instance), includes the customer type, also included in the reservations domain. Structural (#) inclusions (e) imply ownership and mean that instances of customers and reservations are managed by the respective domains. By contrast, a nondescript inclusion (f) means that customers appear in the reservations domains but are not managed there.
While there are sound design solutions to overlapping domains (e.g., SOA or DDD), the objective here is to ensure a neutral representation of shared domains through ontologies.
To that effect, Customer and ReservationDiner types, while defined and managed independently in business specific domains, also realize functional templates of Party≈ and Reservation≈, respectively; with realization connectors set explicitly (g), or implicitly with OWL subtypes (h).
Moreover, shared and reused artifacts can be defined as templates, or more specifically as profiles or patterns:
- Profiles are used in descriptive models when references to environment are involved, e.g., for parties (i)
- Otherwise patterns can be used for both descriptive and prescriptive artifacts (j)
Domains can thus enable a finely grained management of shared and reused assets with regard to contexts (enterprise organization vs system architecture) as well as of concerns (business vs engineering):
- Modeling level: descriptive domains set according to business units, prescriptive ones set along system functional architecture.
- Modeling templates: domain profiles for representative features of environments, domain patterns for representative features of artifacts.
Domains & Use Cases
As already noted, a primary objective of domains is to balance the authority and autonomy of business units with the consistency and sustainability of representations. That can be best achieved if use cases giving access to domains are defined accordingly:
- Business cases, giving access to enterprise domains, associated with organizational units
- Use cases, giving access to application and objects domains, associated with roles defined at the enterprise level
- System cases, giving access to system domains, associated with system agents identified at the system level
Use cases will be considered in the next session.