1.3 KiB
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.