ddd4j Metrics

Overview

Metrics must describe observable behavior and keep cardinality low; the current first-party implementation centers on ProjectionMetrics and OpenTelemetryProjectionMetrics, with other capabilities extended per real adapter.

When to Use

• Instrumenting projections via the ProjectionMetrics port and the OpenTelemetryProjectionMetrics adapter — success/failure, processed count, duration, position lag.
• Designing metric sets for Web, MQ, Cache, or Runtime capabilities (request count, ack/nack, hit/miss, startup/readiness).
• Reviewing label design and rejecting high-cardinality or PII-bearing labels (tenant, user id, message id).
• Deciding whether a Noop metrics implementation means observability is present (it does not — it is a degradation).
• Writing metric tests: names, label sets, increments, and exception paths.
• Distinguishing what metrics can claim from what logs, traces, readiness, and business acceptance must prove separately.

When NOT to Use

Do not use this skill when: