Anti-porous architecture: a unified design principle for CQRS + Actor + Event-Sourcing systems
Description
This paper is an analytic theory contribution in the sense of Gregor (2006, theory for analyzing, Type I): it introduces a new construct (porosity) and an analytic frame (the encoding decision underneath four surface manifestations), and presents one instantiation as existence proof that the inverse encoding is realizable in production. Quantitative evaluation of the instantiation is deferred to a companion case-study paper; the present paper's contribution is the analytic frame, not artifact evaluation.
Four bodies of literature — relational database theory, domain-driven design, REST API contract design, and Event Sourcing — independently document a recurring representational defect: schemas that mix unrelated concepts, fields populated for some rows but not others, contracts overloading heterogeneous use cases behind optional parameters, event payloads recording what was sent rather than what was used. Each tradition names the defect locally and prescribes a local remedy.
This paper argues that the four are surface manifestations of a single architectural decision — structure-centric encoding, the choice to make the representation primary the type-space the form must serve rather than the operation that determined the specific case. We name the defect porosity and its principled inversion (operation-centric encoding cross-layer) anti-porosity, and identify the three simultaneous conditions a CQRS + Actor Model + Event Sourcing combination must satisfy to sustain it.
A system descending from a 2005 wrapper, refined across multiple projects and ported from Java to .NET, has run continuously in production since 2018 satisfying these conditions; that system, Puppeteer, is presented as one realization, not as the foundation of the claim.
Series information (English)
Paper 1 of the Puppeteer Papers Series — the foundational entry point of a research program in seven papers around journaled-program substrates and their structural consequences for software architecture.
A unified monograph integrating all seven papers (Puppeteer: Journaled Programs and the Dissolution of Infrastructure) is available at https://github.com/alvaroNCubo/puppeteer-papers/blob/main/puppeteer-monograph.pdf.
Subsequent papers in the series:
- Paper 6: Most infrastructure layers are symptoms of the persistence model (DOI: 10.5281/zenodo.20317450)
- Paper 7: After the substrate: building software without a datacenter (DOI: 10.5281/zenodo.20398998)
- Papers 2-5 will be deposited as their drafts settle.
Technical info (English)
Source-code references in this paper resolve against commit b42d0f7 of https://github.com/alvaroNCubo/puppeteer (2026-05-26), archived in Software Heritage at:
swh:1:dir:177e2d61486bdbdfd2d5e774fcf392a45406e60d
;origin=https://github.com/alvaroNCubo/puppeteer
;anchor=swh:1:rev:b42d0f76b4278c36a45c221cc1453e3ee8ffb3de
A prior snapshot (commit 2f31f96, 2026-05-18) is also archived at swh:1:dir:10e7e6bad7eb77b6c2e406762026177f95c3ae92 for historical reference. Inline references of the form file.cs:NN in the paper resolve against b42d0f7; line numbers remain stable across the two snapshots.