glm-5.1
19b3d3a078
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.
45 lines
2.0 KiB
Markdown
45 lines
2.0 KiB
Markdown
---
|
|
id: architecture/adr-032-event-boundary-discipline
|
|
name: Write ADR-032 — Event boundary discipline
|
|
status: completed
|
|
depends_on: []
|
|
scope: single
|
|
risk: low
|
|
impact: project
|
|
level: 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:
|
|
|
|
1. **Domain events** (Honker streams) — internal to the owning service, for state reconstruction. Never cross service boundaries without projection.
|
|
2. **irpc service calls** — synchronous request-response, within a node or cluster. Internal to the system.
|
|
3. **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 |