The Logical View

The Logical view is the functional structure — the objects, the types, and how they relate. It answers the designer's question: what is this system, as a set of concepts? Before you ask what runs at once, or where the parts live, or how the source is packaged, you ask what the parts are. That is the logical view, and it is the one most engineers already draw without naming — the boxes-and-arrows sketch of the domain.

Two general model types live here. A data-flow diagram traces what data exists and who may touch it. An inheritance hierarchy shows which specializations of an abstract concept exist. Two of the catalogue's real models embody the view on live code: the service-flow model, which is the functional structure of a service-oriented architecture, and the domain registries, which are the typed facts that functional model rests on.

Inset I5 — What is a data-flow diagram?

A data-flow diagram traces data moving through transforms — a source, the stages that reshape it, and the sink — where each edge names what flows across it, not what decides. It differs from a control flowchart: a flowchart's diamonds branch on decisions; a data-flow's edges carry a document, a JSON blob, a rendered page. It is the natural lens for security and privacy, because the question there is exactly "where does this data go, and who may touch it on the way?" Draw it left to right, label each edge with the data on the wire, and a reader sees the path a piece of data takes and every component that handles it.
flowchart LR
  Doc[/Raw document/] -->|bytes| Parse[Parse]
  Parse -->|typed model| Remediate[Remediate]
  Remediate -->|stamped model| Write[/Output document/]
Accessible description: a raw document enters as bytes, is parsed into a typed model, remediated into a stamped model, and written out — each edge naming the data that crosses it, so a reader can see every component that touches the document.

An inheritance hierarchy — the second logical-view type — shows an abstract concept and its concrete specializations, so an engineer sees which extensions exist and where a new one would attach. A remediation tool's inheritance hierarchy names the abstract "document format" and its concrete leaves — the slide format, the word-processor format, the spreadsheet, the PDF — each carrying the same operations against a different file model. The hierarchy is the logical statement of what kinds of thing the system knows how to handle, and it is where a reader looks to answer "can this system be extended to a new format, and what must the new leaf provide?"

The two real models below carry the view. The data-flow and inheritance types are the vocabulary; these are the worked embodiments.

The service-flow / API model

The typed source-of-truth for a service-oriented architecture — its services, their endpoints, their authentication, and the wiring between them — from which the access policy and environment wiring are generated and against which the real call graph is checked.

(a) Quality property it helps assess. Three, each a question the scattered deploy config and handler code cannot answer without a single model.

Wiring correctness: does every declared caller-to-callee edge have a real call site, and every real cross-service call a declared edge? An undeclared call is an ungoverned one.
Access-policy soundness: does the generated network access policy match the wiring the model declares? The policy is emitted from the model, so a service can reach only what the model says it may.
Contract parity: does each endpoint's declared request and response shape match the handler that serves it? A drifted contract is a runtime failure the model turns into a build failure.

(b) Constructs and relations. A typed catalog in the dialect of a service-catalog schema, adopted for its hard-won structure and read by the project's own tools.

Service: one deployable unit, with its name, its owning layer, and the endpoints it serves.
Endpoint — one API surface on a service: its path, its auth requirement, and its declared request and response contract.
Wire: one declared caller-to-callee edge, joining a calling service to a called endpoint. The set of wires is the graph the access policy is generated from and the call graph is checked against.

(c) Visual depiction. The natural diagram is a data-flow — the model on the left, the generators and parity gates it feeds on the right. Reused from the model's appendix Structure slot:

flowchart LR
  M[(Service model)] --> Gen[Generators]
  Gen --> Policy[/Access policy/]
  Gen --> Env[/Env wiring/]
  Reality[(Trees + handlers)] --> P{Parity gates}
  M --> P
  P -->|either side diverges| Fail([build blocked])

Accessible description: the service model feeds generators that emit the access policy and environment wiring, and it feeds parity gates that compare it against the real service trees and handlers. When either the model or reality diverges, the build is blocked. The model is authoritative for what it generates and reconciled against reality for what it checks.

(d) Invariants, and how they are checked. The checkers are the trunk drift-and-parity machinery, pointed at the service graph:

Invariant	Temporal shape	How it is checked
Every declared wire has a real call site	□P (safety)	Call-graph parity lint: each `Wire` edge must resolve to a real cross-service call.
Every real cross-service call is a declared wire	□P (safety)	Same lint, reverse direction — an undeclared call is a finding.
The generated access policy matches the wiring	□P (safety)	Freshness lint over the generated policy: regenerate from the model, diff against the committed artifact.
Each endpoint's contract matches its handler	□P (safety)	Contract parity check joining the `Endpoint` shape to the handler signature.

(e) Traceability and derivation direction. Bidirectional. The access policy and environment wiring are model-to-code — generated from the declared model. The call-graph parity runs model-from-code — it re-reads the real call sites and reconciles. The join key from a model row to the code is the endpoint path, which indexes both a Wire edge and the handler that serves it.

Also seen in: Physical (the generated access policy is a placement artifact). Rendered in full here; referenced from the Physical chapter.

The domain registries

The domain registries are the frozen tables the service-flow model rests on: the file types the system handles, its known conformance gaps, its scheduled jobs, its user-facing surfaces. Each is the single source of truth for its slice — the competitor doc, the coverage table, and the code that switches on file type all read the same frozen registry, so they cannot disagree. The quality property is fact consistency: every place that presents a domain fact agrees, because each joins to the registry by key rather than keeping its own copy. The idea worth carrying is the flip side of that join — a snapshot-ban lint. Copying a registry value into code is itself a finding, because the copy is where drift starts; the consumer must read the fact live or be caught. That turns "keep the docs in sync" from a discipline into a build failure. Its full construct-and-invariant treatment is in the appendix, and one slice — the governance rules' own metadata — is walked in full in the Development chapter as the rule-metadata registry.

---

The Logical view names what the system is. The next chapter asks the question the logical view cannot: not what are the parts but what happens when many of them run at once. That is the Process view, and it is where invariants stop being predicates over one state and start being predicates over an interleaving.