The Art of Structuring, Part 2 — Structuring Meaning, Relationships, and Execution

Part 1 established the boundaries and identity of entities, then considered how to create multiple projections for different uses.

Part 2 follows the axis of concern to separate meaning, relationships, behaviour, execution, access, communication, and storage. It then follows the axis of domain to organise design responsibility across business, data, application, and technology. It also covers the context that links every representation back to the same entity.

1. Concern: specifying meaning and relationships

The axis of concern separates what each view says about the same entity. This section moves from the meaning of fields to mappings between terms and then to relationships between entities.

1.1 Carrying field meaning into the specification

Suppose a customer record has string fields named id, name, and status; id is required; and status is limited to active or inactive. Those rules let us validate the presence of fields, their data types, and their range of values. JSON Schema Draft 2020-12 likewise defines a mechanism for describing the structure and validation rules of JSON documents.

That definition does not tell us who issues id, within what scope it is unique, or what condition status = active represents. If id is a customer ID, the specification must state that it refers to a customer entity and whether it is unique within a tenant or across the entire system. For status, it must define whether active means that the customer may trade or merely that the customer may be contacted.

Units and the scope of comparison also belong to a field’s meaning. If the integer 100 represents money, its currency is required; if it represents processing time, a unit such as milliseconds is required. Carrying the target of a reference, a unit, the meaning of a state, and the range of comparable values into the logical specification makes it possible to detect misuse between values that happen to share the same string or integer type.

Sharing meaning across systems requires more than defining individual fields. It also requires a mapping between different terms and the concepts they denote.

1.2 Connecting different terms with a controlled vocabulary

Suppose one system records an operating environment as prod, another as production, and an operations register as 本番. Cross-system search is impossible until all three values are mapped to the same concept. A controlled vocabulary assigns a preferred label and alternative labels to each concept, allowing source labels to remain intact while being converted to a common search condition. The SKOS Reference defines a vocabulary for representing concepts, preferred and alternative labels, and broader and narrower concepts in RDF (Resource Description Framework).

When a server must be found by operating environment, region, owner, and criticality, each of those can be treated as an independent classification axis called a facet. A classification scheme that uses broader and narrower terms is a taxonomy. Facets suit search conditions that users combine independently; a taxonomy suits navigation through hierarchies such as product or organisation classifications.

An ontology adds relationships, constraints, and inference rules to concepts. It may define people, organisations, and services as concepts, then describe membership, ownership, and dependency relationships and their constraints. The OWL 2 Overview describes a family of languages for expressing classes, properties, and individuals and for deriving logical consequences from explicit knowledge.

After concepts, labels, and relationships have been defined, the logical model can be represented as RDF, relations, documents, or a property graph. RDF 1.1 Concepts and Abstract Syntax defines an RDF graph as a set of subject-predicate-object triples. Separating vocabulary and relationship design from the storage format allows the same conceptual system to be used in a data format suited to each use case.

1.3 A logical representation suited to the relationships

Choose a logical representation according to the direction and number of relationships it must preserve and whether cycles are allowed. A tree can represent direct reporting lines when each person has at most one manager. A graph becomes a candidate when multiple parents are allowed, as in concurrent assignments or project membership. A build dependency model that must remain acyclic can use a DAG (Directed Acyclic Graph).

A relationship specification describes whichever properties the queries and validation require: direction, cardinality, containment, cycles, and reachability. A service catalogue represented as an attribute table supports searches by owner or criticality; represented as a dependency graph, it supports exploration of failure propagation paths. First define the relationships to preserve and the queries to execute, then choose a logical representation, and only then choose a database product or storage format.

2. Concern: specifying behaviour, process, and computation

Once entity attributes and relationships are established, the specification must describe how state changes, how work is divided into processing steps, and how those steps are assigned to execution units. This section covers state transitions, the granularity of retryable tasks, and execution-environment units.

2.1 Order states and permitted transitions

An order represented as the tuple id, customer_id, and total captures information at one point in time. Processing it from acceptance through delivery also requires states, events that change those states, and conditions that permit each transition.

accepted → confirmed → paid → shipped → delivered

This state machine defines the condition for moving from paid to shipped, the states in which cancellation is possible, and the point to which processing returns after a failure. An information view that represents order attributes and a behavioural view that represents how the order changes are separate projections of the same order.

The introduction to UML includes diagrams for behaviour—activity, state-machine, and sequence diagrams—alongside diagrams such as class diagrams for static relationships. Describing permitted transitions and operations as a behavioural specification, instead of making decisions from an enumeration in a status field alone, allows screens, APIs, and batch processes to apply the same rules.

2.2 Task granularity and the scope of a retry

If shipping fails after payment has completed, retrying the entire flow from order acceptance requires protection against duplicate payment. Separating payment and shipping into different tasks allows shipping alone to be retried, but requires the state and dependency between tasks to be managed. The task boundary changes both the processing that is retried and the state that must be retained.

A business process describes the order, owner, starting condition, and exceptions for order acceptance, inventory checks, payment, shipping, and billing. The BPMN 2.0.2 specification uses events, activities, gateways, sequence flows, and message flows to describe processes within an organisation and collaboration between participants.

When a process in the business domain is carried into an application specification, one business activity may be divided into authorisation, recording, notification, calls to external services, and other functions. A business activity and an application task need not have the same granularity. Define the input, output, state, and retry starting point of each task separately.

2.3 Application processing and execution-environment units

Jobs, stages, and tasks are execution units for application processing. Processes, threads, and coroutines determine the scope of parallelism and resource sharing in the execution environment. One possible design treats a single order aggregation as a job, each partition of the aggregation range as a task, and runs several tasks in threads within one process.

The POSIX overview of threads describes a thread as a unit with its own execution state that shares the resources of a process. Jobs and tasks manage processing dependencies and retries; threads are units to which runtime resources are assigned.

An execution-unit specification carries in the properties needed to control processing, such as dependencies, parallelism, cancellation, timeouts, retries, and resource isolation. Separating the business process, application processing, and execution environment allows a business failure and a process or thread failure to be recovered within different scopes.

3. Concern: deciding the units of access, communication, and storage

The axis of concern also asks how an entity is reached, in what unit it is transferred, and in what unit it is stored. This section covers file access paths, communication units, and storage placement units.

3.1 One file, multiple paths

In a file system, the path /home/alice/report.md is resolved from the root through home, alice, and report.md. Because each directory creates a separate naming scope, the local name config.json can be reused in different directories.

A file’s path and its underlying object use different means of identification. The Linux kernel documentation on pathname lookup explains how a path is split into components and resolved through directory entries and inodes. Multiple hard links can refer to the same inode, while a symbolic link adds another reference relationship to path resolution.

A specification that handles files distinguishes path-based access, file identity, and physical placement. A path is an access method in a namespace; file contents are placed in extents and blocks.

For example, if a configuration file refers to /mnt/reports/current.csv, the path must be updated when the mount point changes. If the use case instead needs to track the same file after its name or location changes, the design can give the file an ID separate from its path.

3.2 Order data changes unit at each communication boundary

The same order request takes different communication units at different processing boundaries. The request “order three units of Product A” may be a CreateOrderCommand at the application boundary, a JSON or Protocol Buffers message at the API boundary, and a byte stream when sent over TCP.

TCP transfers a byte stream, while sending and receiving operate on segments with sequence numbers. RFC 9293 defines a TCP segment as the logical unit of data transferred between TCP modules and defines fields such as sequence number, acknowledgement number, length, and window. At the IP layer, it is wrapped in a packet containing a source address, destination address, next-header field, and other fields specified by RFC 8200 for IPv6.

The order message contains the product and quantity; the TCP segment contains the information required for ordering and retransmission; the IP packet contains addresses required for routing. The application specification determines payload fields such as order ID, product, and quantity. The communication protocol determines the units and metadata required for transfer, segmentation, and retransmission.

Retrying order processing and retransmitting TCP data have different subjects and responsibilities. Packet retransmission cannot guarantee the application rule that prevents the same order from being registered twice. The units and failure-recovery scope handled by each domain must be designed separately.

3.3 Storage placement according to the unit of I/O

At the logical level, an order entity may be designed as a relation or document. At the physical level, it is placed into records, pages, extents, and blocks; distributed storage assigns partitions and shards by key range or hash.

A columnar file is a physical projection of the same logical table for analytical I/O. Apache Parquet divides a file into a hierarchy of row groups, column chunks, and pages. Placing values from the same column near one another allows a reader to load only required columns and apply type-specific encoding and compression.

The units to which reads, writes, caching, replication, recovery, and consistency apply differ by storage scheme. One design may use pages as the unit of I/O and caching, and partitions as the unit of placement and replication. If the whole must be reconstructed after it is split, select the necessary metadata from the parent identifier, ordering, offset, length, and checksum.

Storage placement depends on whether downstream processing updates one item, reads selected columns in bulk, or recovers a particular range after failure. Preserve the logical order entity while designing physical units suited to I/O and recovery.

The order entity, command, message, packet, record, and page each have their own IDs and units within their respective domains. Tracking them as data derived from the same order requires context that crosses those domains.

4. Domain: treating the same order across four design scopes

The axis of domain distinguishes whether a design decision belongs to business, data, application, or technology. The Open Group’s explanation of how TOGAF and ArchiMate complement each other likewise identifies these four architecture domains. Although every domain handles the same order, each determines something different.

The business-domain activity of accepting an order is managed as an order entity in the data domain and carried into specifications for CreateOrderCommand and APIs in the application domain. The technology domain places that processing and data into processes, networks, databases, and storage.

A domain identifies the scope for which a design is responsible. Fields in an order message, for example, belong to the application domain, while packet transfer belongs to the technology domain. Even when artefacts have similar forms, record separately the domain to which the reason for change and responsibility belong.

5. Context: tracking one entity across domains

When multiple representations are created from one entity, IDs, times, constraints, sources, and transformation rules also diverge by representation. Context records the information needed to map between them and to trace the basis of values and decisions.

5.1 Names and addresses versus identity

Company names, file paths, process IDs, and IP addresses can refer to entities, but do not necessarily remain in one-to-one correspondence with them. A company can change its name; a file can have several paths through hard links; a process ID is reused after termination; and an IP address can be reassigned to another host.

An identity specification defines not only what is treated as the same entity, but also the issuer, scope, validity period, and reuse policy of an identifier. If order number 1234 identifies different orders in Tenant A and Tenant B, one design can use the pair tenant_id and order_id; another can convert both into order IDs that are globally unique.

To track a database order record, API message, and log event as the same order, link each identifier to the order ID. Do not reuse a name or location as an identity rule; record which entity each domain’s identifier refers to.

5.2 Valid time, recording time, and event order

The temporal context distinguishes the time when a fact was valid, the time when the system recorded it, and the ordering between events. The relationship “Service A is owned by Team B” has a start and end of validity; the time when it was entered into a register is separate. Register an organisational change retroactively and the fact’s valid time will differ from the time when the system learned it.

Overwriting only the current value makes it impossible to answer who owned a service during a past incident. A system that constructs current state from event history can retain that history as the source of truth and provide a projection for retrieving the current value quickly. The states that must be answered for particular points in time determine which timestamps and how much history to retain.

In a distributed system, wall-clock time may not be enough to order events. Leslie Lamport’s paper Time, Clocks, and the Ordering of Events defines the happened-before partial order from ordering within one process and from message sends and receives. It does not impose an order on events with no causal relationship. When carrying time into a specification, choose valid time, recording time, and causal order according to the queries the system must answer.

5.3 Constraints that make relationships and state transitions valid

Constraints limit the states that relationships and state transitions may take. A tree, for example, gives each node at most one parent and forbids cycles. Business invariants may state that total payments cannot exceed the order total or that a contract’s end date cannot precede its start date.

If an invariant exists only in screen-level input validation, another update path such as an API or batch job can violate it. Define where and by whom the rule is enforced—through database constraints, application validation, state-transition guards, or another mechanism—so that every update path can validate the same condition.

Purpose-specific projections also have constraints that must survive transformation. Whether a graph or relations are chosen, the design must still be able to validate cardinality, uniqueness, referential integrity, and temporal ordering. The Shapes Constraint Language, SHACL, defines shapes and constraints for RDF graphs and a mechanism for validating data graphs. Recording the rule and its validation location as context allows the same rule to be applied to multiple representations and update paths.

5.4 Provenance and versions for revalidating decisions

Validating an integrated value requires its source, observation time, and selection rule. A configuration-management register might identify a service’s owner as Platform Team, a repository’s CODEOWNERS as Core Team, and a service catalogue as Infrastructure Team. If an integration process selects one value, retain both the selected source and the selection rule.

The W3C PROV Data Model represents as provenance the entities, activities, and agents involved in producing data or things. By structuring the source record, transformation, and agent separately, it becomes possible to trace the inputs and activities from which a derived value arose.

In record linkage and AI extraction, observed facts must remain separate from inferences. Re-evaluating the conclusion that “these two records probably represent the same corporation” requires the compared attributes, the model or rule version, a score, and the time of the decision. If only the conclusion is stored as a fact, records that require re-evaluation cannot be found after the rule changes.

Versioned subjects include entity state, schemas, ontologies, protocols, file formats, and transformation rules. For example, entity_version can identify an entity’s history, schema_version the applied schema, rule_version the transformation rule, and projection_version the procedure that produced derived data. Combining all of these into one field called version leaves it unclear what the number revises.

To update multiple projections independently while treating the same facts, record as context the entity, point in time, constraints, source, and transformation-rule version referenced by each projection. Linking inputs, decisions, transformations, and outputs makes it possible to identify data affected by a rule change and rebuild a projection under the same conditions.

The same entity takes different units of representation according to concern and domain.

Part 3 covers representations suited to particular queries and the reconstruction and operation of transformed data.