Files
Stéphane Tailland b62b92fe1a Add the procurement topic and Supply's write access to it
reorder.requested and its answer (confirmed/rejected) share the topic, keyed
by the reorder id, so ordering between the ask and the answer holds the way it
does for a product's own facts on classic-models.catalog.

Supply both writes and reads this topic — one service, two capacities, not a
separate procurement identity, per the 2026-08-31 decision.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
2026-08-31 16:17:05 +02:00

155 lines
4.3 KiB
YAML

# The classic-models estate on the shared Kafka cluster.
#
# Everything here is created in the `kafka` namespace, because that is the only
# one Strimzi watches (`watchAnyNamespace=false`). A CR elsewhere is ignored in
# silence — no status, no Secret, no log line.
#
# The events these topics carry are specified by their producer, in
# classic-models-api/docs/DOMAIN_EVENTS.md. This file grants access; it does not
# define meaning.
# --- topics -----------------------------------------------------------------
#
# One per aggregate, not one per event type: per type would lose the order
# between product.created and product.stock_changed for the same product, which
# is the one ordering a consumer actually needs.
#
# Declared rather than auto-created — the accounts below have no Create ACL, so
# a producer would simply be denied, and an auto-created topic takes broker
# defaults nobody chose. Partition count is the ceiling on consumer parallelism
# and cannot be lowered later.
---
apiVersion: kafka.strimzi.io/v1
kind: KafkaTopic
metadata:
name: classic-models.catalog
namespace: kafka
labels:
strimzi.io/cluster: kafka
spec:
partitions: 3
replicas: 1
config:
retention.ms: "604800000" # 7 days
cleanup.policy: delete
min.insync.replicas: "1"
---
apiVersion: kafka.strimzi.io/v1
kind: KafkaTopic
metadata:
name: classic-models.sales
namespace: kafka
labels:
strimzi.io/cluster: kafka
spec:
partitions: 3
replicas: 1
config:
retention.ms: "604800000"
cleanup.policy: delete
min.insync.replicas: "1"
---
apiVersion: kafka.strimzi.io/v1
kind: KafkaTopic
metadata:
name: classic-models.payments
namespace: kafka
labels:
strimzi.io/cluster: kafka
spec:
partitions: 3
replicas: 1
config:
retention.ms: "604800000"
cleanup.policy: delete
min.insync.replicas: "1"
---
# A supply request and its own answer, on one topic: reorder.requested and its
# eventual reorder.confirmed/reorder.rejected share a subject — the reorder id
# — so ordering between "asked" and "answered" holds the way it does for a
# product's own facts on classic-models.catalog.
apiVersion: kafka.strimzi.io/v1
kind: KafkaTopic
metadata:
name: classic-models.procurement
namespace: kafka
labels:
strimzi.io/cluster: kafka
spec:
partitions: 3
replicas: 1
config:
retention.ms: "604800000"
cleanup.policy: delete
min.insync.replicas: "1"
# --- accounts ---------------------------------------------------------------
#
# One direction each, on one prefix. A producer that could also read every topic
# exfiltrates every other application's data if it is ever compromised, and a
# consumer that could write can raise an event someone else acts on.
---
# classic-models-api. Publishes domain events, consumes nothing.
apiVersion: kafka.strimzi.io/v1
kind: KafkaUser
metadata:
name: classic-models-api
namespace: kafka
labels:
strimzi.io/cluster: kafka
spec:
authentication:
type: scram-sha-512
authorization:
type: simple
acls:
- resource:
type: topic
name: classic-models.
patternType: prefix
operations:
- Write
- Describe
---
# The supply agent. Reads the catalog topic — its job is stock, it has no
# business reading who paid what. It also both writes AND reads its own
# procurement topic: it raises a reorder request and answers its own request
# a moment later (this is one service acting in two capacities, not two
# services, per the 2026-08-31 decision that réapprovisionnement stays one
# service rather than splitting into a separate procurement identity).
apiVersion: kafka.strimzi.io/v1
kind: KafkaUser
metadata:
name: classic-models-agent-supply
namespace: kafka
labels:
strimzi.io/cluster: kafka
spec:
authentication:
type: scram-sha-512
authorization:
type: simple
acls:
- resource:
type: topic
name: classic-models.catalog
patternType: literal
operations:
- Read
- Describe
- resource:
type: topic
name: classic-models.procurement
patternType: literal
operations:
- Read
- Write
- Describe
- resource:
type: group
name: supply-
patternType: prefix
operations:
- Read
- Describe