Technology Matrix
One property per row, kept by a different technology in each column.
Non-normative
- Companion version
- 1.0
- Maps to COADF Core
- 2.2
- Status
- Current
- Last reviewed
Each row is one architectural property; each column shows how one stack can keep it. The point of the matrix is that the property stays the same while the technology changes.
The matrix does not rank the stacks, and no column is recommended.
Boundary validation
Principles: P-1
- Java and Spring
- Jakarta Validation on request types with
@Valid, and again in the domain factory - Python and FastAPI
- Pydantic models with
extra="forbid"and strict mode; FastAPI answers invalid input with 422 - TypeScript and Node
- A Zod or JSON Schema at every receiving side, with the type inferred from it
- Cloud-Native and Kubernetes
- Not an infrastructure property: admission never sees application data
Runtime schema validation
- Java and Spring
- Bean constraints, and an explicit policy on undeclared properties for boundary types
- Python and FastAPI
model_validate_jsonon the raw reply; an explicit response model- TypeScript and Node
safeParsewith strict objects; Ajv behind Fastify route schemas- Cloud-Native and Kubernetes
- Strict schema validation of manifests before they are applied
Trace propagation
Principles: P-4
- Java and Spring
- Micrometer Tracing with the OpenTelemetry bridge; context-propagating task decorators
- Python and FastAPI
- OpenTelemetry
injectandextract; the context copied into threads - TypeScript and Node
- OpenTelemetry JS with the AsyncLocalStorage context manager
- Cloud-Native and Kubernetes
- OpenTelemetry SDK settings per workload; W3C Trace Context by default
Persistent audit trail
Principles: P-4
- Java and Spring
- Entries written in the business transaction; database grants and triggers
- Python and FastAPI
- PostgreSQL with an insert-only role, refusal triggers and idempotent writes
- TypeScript and Node
- The same PostgreSQL schema through a driver, in the business transaction
- Cloud-Native and Kubernetes
- The application's own store, never the telemetry pipeline
Policy evaluation
Principles: P-8
- Java and Spring
- A domain-owned interface with an OPA adapter, or rule tables
- Python and FastAPI
- OPA over its REST API behind an interface; no decision without a revision
- TypeScript and Node
- OPA over HTTP, or Rego compiled to WebAssembly and evaluated in process
- Cloud-Native and Kubernetes
- OPA as a service or sidecar, with bundle revisions in the decision logs
Architecture testing
- Java and Spring
- ArchUnit rules, or Spring Modulith verification
- Python and FastAPI
- import-linter contracts
- TypeScript and Node
- dependency-cruiser, ESLint boundary rules, or project references
- Cloud-Native and Kubernetes
- Tests for manifests and for the admission rules themselves
CI enforcement
Principles: P-6
- Java and Spring
- Architecture and contract tests as required checks
- Python and FastAPI
- Import contracts, negative tests and the publication fence as required checks
- TypeScript and Node
- Dependency rules, schema tests and contract tests as required checks
- Cloud-Native and Kubernetes
- A summary job that fails when any fence failed or was skipped
Standards isolation
Principles: P-7
- Java and Spring
- Port interfaces in the domain module; one adapter module per vendor
- Python and FastAPI
- A
typing.Protocolport and an adapter that alone knows the vendor - TypeScript and Node
- Port interfaces; one adapter package per vendor in the workspace
- Cloud-Native and Kubernetes
- Egress to each external service allowed explicitly, and nothing else
Observability
Principles: P-4
- Java and Spring
- Micrometer Observation
- Python and FastAPI
- The OpenTelemetry API and SDK
- TypeScript and Node
- The OpenTelemetry JS SDK, preloaded, with the loader hook for ES modules
- Cloud-Native and Kubernetes
- An OpenTelemetry Collector pipeline, which may sample
Deployment enforcement
Principles: P-6
- Java and Spring
- Delegated to the platform the service runs on
- Python and FastAPI
- Delegated to the platform the service runs on
- TypeScript and Node
- Delegated to the platform the service runs on
- Cloud-Native and Kubernetes
- ValidatingAdmissionPolicy or Gatekeeper; images by digest; revisions on every object
