EDUCE Overview Copyright 2009 Nikolas S. Boyd.
All rights reserved.

Domain Vocabulary

Intent

Capture business elements, facts, relationships, policies, and procedures in a comprehensive domain vocabulary.

Motivation

Creating useful and usable software solutions requires effective communication among solution stakeholders. So, creating a shared understanding of business policies, problems, and practices is the primary challenge facing a software development team. The degree to which all the various stakeholders share their (sometimes diverse) understandings, viewpoints, and needs affects their conceptual commonality.

The various stakeholders need to express and share many kinds of ideas, including vision, mission, values, viewpoints, interests, wants, needs, goals, conditions, situations, alternatives, options, requirements, roles, relationships, responsibilities, collaborations, events, qualities, quantities, and measures.

Without a common vocabulary and shared conceptual models of a business opportunity and its attendant problem(s), the effectiveness of a software development team and the likelihood that the developed solution will achieve its intended ends are substantially reduced (if not utterly doomed).

So, how can we ensure that business policies, problems, and practices are not merely understandable, but actually understood by all stakeholders? Discussing, capturing, crunching, and reviewing business and technical knowledge manufactures commonality between the members of a software development team and the solution stakeholders.

Applicability

Use a domain vocabulary when

Considerations

A comprehensive, published domain vocabulary serves as a natural repository for business domain and solution requirements knowledge. A domain vocabulary focuses on business domain elements and their relationships. Thus, a domain vocabulary will naturally focus on topical subjects and the predicates that surround those subjects, especially those predicates describing the relationships between subjects, and the associated business practices and policies.

Maintaining a domain vocabulary in an on-line repository provides an effective mechanism for sharing domain and requirements knowledge thoughout an (often distributed) organization and development team. A Wiki (with hypertext links between related topics) provides one of the more convenient and effective ways to host a domain vocabulary in an on-line repository.

While other narrative and structured descriptions will often be generated to serve solution development, the essential form of a domain vocabulary will include a list of domain elements (as nouns or noun phrases) and their attendant predicates (as verb phrases). The verb phrases are assembled from the nuclear sentences extracted from policy statements, problem descriptions, and solution usage descriptions. Consider the following list excerpted from a sample problem domain:

drum
contains a hazardous chemical
has a volume capacity (quantity + unit of measure)
drum contents
is a hazardous chemical
has a category (hazard type)
has a volume (quantity + unit of measure)
has a weight (quantity + unit of measure)
drum identifier
identifies a drum in the system
drum identification label
identifies a drum within the depot premises
indicates the drum identifier
indicates the drum contents, measurement(s) and hazard type

Consequences

A domain vocabulary can be used to integrate viewpoints from multiple stakeholders. Stakeholders may offer complementary views of interactions with domain elements or relationships between domain elements. These complementary views help complete and stabilize the conception of those domain elements.

A domain vocabulary may highlight differences in stakeholder viewpoints and biases. It may help resolve what might otherwise become conflicts through differences of opinion (esp. those based on differences in viewpoint). Some of these apparent differences of viewpoint may indicate that there are bounded contexts within which a given concept will be construed differently.

Fortunately, software solutions are soft. Thus, such differences can often be accommodated simply by offering different solution users different views of the same underlying domain model.