Objective
Given that perceptions are driven by concerns, symbolic representations must be organized accordingly. That is the objective of domains, which identify objects and activities of concern, select relevant features, and define their semantics and uses.
- Domains organize knowledge depending of concerns and meanings.
Domains can be seen as undersides of ontologies, as they are driven by purposes, contrary to ontologies meant to deal with meanings.
What’s in a Name
“In the beginning was the word …”. Things must be named before anything can be done with them, but there is an infinity of things, subject to an infinity of purposes. Hence the need of domains to manage meanings for whom may be concerned.
Domains are symbolic containers managed by organizational units sharing a common understanding of objects and activities. Despite some variations, there is some consensus about the basic idea, namely a community of meanings. Along that line, the concept may be applied at different levels, e.g Domain Driven Design (DDD) distinguishes between “domain”, for business concerns and objectives, and “bounded contexts” for detailed semantics.
Business & Application Domains
Whatever the methodological framework, the definition of domains must take into account the two dimensions of the naming game, namely target and purpose. In other words semantics can be shared at structural (business) or functional (application) level.
- Business domains define the structure and semantics of business objects whose integrity and consistency has to be persistently maintained independently of activities using them. Those domains will govern objects life-cycle (create and delete operations) and identification mechanisms (fetch operations). That would target objects, agents, events and processes identified independently of systems.
- Application (aka functional) domains define the structure and semantics of transient objects whose integrity and consistency has to be maintained while in use by activities. Those domains will govern features (read and update operations) and target aspects and activities rooted (aka identified) through primary objects or processes.
- Each domain minds its own business.
That distinction is consistent with both Object and Aspect Oriented approaches and can be maintained across model layers.
Hence, business domains are set at corporate level and bound to corporate identity while application domains are from the point of view of activities and bound to business opportunities.
- Application Domains share objects but not visions
Business as well as applications domains can be used to define the format and semantics of features, operations, and rules specific to the domain.
- Business transactions call for a common language
Domains vs Repositories
Domains deal with the ownership of semantics and must not be confused with representations containers (aka repositories), which deal with the ownership of symbolic representations. Yet, domains can actually be associated with symbolic containers when they are mapped into organizational repositories with corresponding access rights. For instance, an organizational unit can define mechanical objects and manage actual records while another one would define repair rules and manage repair operations.
- Domains and symbolic containers: the same units can set the rules and manage the objects
Domains & Knowledge
Domain modelling plays a pivotal role when business objects or processes are to be shared or consolidated. On the business hand they deal with knowledge contents, on the system hand they describe how it can be accessed; while both kind of models can appear as requirements, they belong to different architectural tiers:
- Domain knowledge is meant to be independent of applications and systems; corresponding models describe the semantics and consistency constraints of persistent representations.
- Application knowledge deals with specific business concerns, and is therefore associated with transient objects. It is usually defined through use cases.
Models of persistent and transient objects can be reconciled using services. Models of contexts and systems can be consolidated in knowledge architecture.
One thought on “Domains”