35 lines
1.3 KiB
Markdown
35 lines
1.3 KiB
Markdown
# 0001: Four-layer platform boundary
|
|
|
|
- Status: Accepted
|
|
- Date: 2026-07-12
|
|
|
|
## Context
|
|
|
|
Ekklesia must remain understandable and independently extensible after many backend capabilities
|
|
and user experiences have been added. A conventional feature monolith or UI-bearing plugin model
|
|
would couple business behavior to a particular presentation framework.
|
|
|
|
## Decision
|
|
|
|
Adopt four explicit ownership layers: Core orchestration, backend Modules, presentation Surfaces,
|
|
and declarative Surface Builder configuration. Begin as a modular monolith. Modules expose data
|
|
and behavior only; every renderer and UI concern belongs to a surface.
|
|
|
|
## Alternatives
|
|
|
|
- A conventional feature monolith was rejected because boundaries degrade as features grow.
|
|
- UI-bearing plugins were rejected because they bind capabilities to frameworks and visual design.
|
|
- Initial microservices were rejected because distribution adds failure modes before contracts
|
|
have been proven.
|
|
|
|
## Consequences
|
|
|
|
Stable contracts, SDK ports, generated composition, and automated boundary checks are required.
|
|
Some integrations take more deliberate service or event design, but modules and surfaces remain
|
|
independently replaceable.
|
|
|
|
## Migration implications
|
|
|
|
Future boundary violations must move behind public contracts before the affected package can be
|
|
treated as independently installable or upgradeable.
|