alknet/tasks/architecture/adr-032-event-boundary-discipline.md at 19b3d3a078afbc1cee842f3e195b9ea09fcbdf94

Files

glm-5.1 19b3d3a078 docs: write Phase 0 architecture foundation — ADRs 026-034, spec docs, and task updates

Phase 0a — ADRs (9 new):
- ADR-026: Transport/interface separation (three-layer model)
- ADR-027: Crate decomposition (core, secret, storage, flowgraph, napi, CLI)
- ADR-028: Auth as irpc service (AuthProtocol behind feature flag)
- ADR-029: Identity as core type (Identity + IdentityProvider in alknet-core)
- ADR-030: Static/dynamic config split (ArcSwap, ConfigReloadHandle)
- ADR-031: Forwarding policy (rule-based allow/deny, TransportKind-aware)
- ADR-032: Event boundary discipline (domain, irpc, call protocol boundaries)
- ADR-033: OperationEnv universal composition (three dispatch paths)
- ADR-034: Head/worker terminology (replace hub/spoke)

Phase 0b — New spec documents (7):
- identity.md, services.md, interface.md, configuration.md,
  storage.md, flowgraph.md, secret-service.md

Updated existing docs:
- auth.md: reference identity.md for canonical definitions, add AuthProtocol
- open-questions.md: resolve OQ-12, OQ-16, OQ-18, OQ-22, OQ-23-25
- README.md: add all new docs, ADRs 026-034

Marked 19 architecture tasks as completed.

2026-06-07 09:32:58 +00:00

2.0 KiB

Raw Blame History

id, name, status, depends_on, scope, risk, impact, level

name

status

depends_on

scope

risk

impact

level

architecture/adr-032-event-boundary-discipline

Write ADR-032 — Event boundary discipline

completed

single

low

project

implementation

Description

Write ADR-032 establishing event boundary discipline as a hard architectural constraint.

The research (services.md, storage.md) identifies three distinct communication patterns with clear boundaries:

Domain events (Honker streams) — internal to the owning service, for state reconstruction. Never cross service boundaries without projection.
irpc service calls — synchronous request-response, within a node or cluster. Internal to the system.
Call protocol events (EventEnvelope) — cross-node, cross-language integration events. These are what cross boundaries.

The ADR must state this as a hard constraint, not a suggestion. Conflating these three patterns is an anti-pattern that leads to leaky event stores and coupling.

Acceptance Criteria

docs/architecture/decisions/032-event-boundary-discipline.md exists
ADR follows established format (Status, Context, Decision, Consequences, References)
Context explains the three patterns and why conflating them is harmful
Decision states: domain events stay within the owning service; irpc calls are synchronous internal boundaries; call protocol events are the only events that cross node boundaries; projection from domain events to integration events is required when crossing boundaries
Consequences include: prevents leaky event stores, services are independently deployable, Honker and irpc are implementation details not exposed across boundaries
References: research/services.md, research/storage.md, integration-plan.md

References

docs/research/services.md — event boundary discipline section
docs/research/storage.md — Honker integration, event boundaries
docs/research/integration-plan.md — ADR 032 entry

Notes

To be filled by implementation agent

Summary

To be filled on completion

2.0 KiB Raw Blame History