Demosplan Core Laravel Package

Technical Evaluation

Architecture fit. demosplan-core is not a conventional reusable package — it is the domain core of DEMOS Plan, a German public-participation and urban-planning (Bauleitplanung) platform used by municipalities and planning agencies. What ships is a large, opinionated domain model — procedures, statements (Stellungnahmen), roles, document/publication workflows, map and GIS bindings — rather than a thin, composable library. Two consequences follow for us. First, value is concentrated in domain logic and legal-process modelling, not in infrastructure, so the fit question is "are we building a formal participation workflow?" and not "do we need a PHP utility?" Second, "core" implies a bundle/extract from a running application; it will likely carry assumptions about its host application (routing, auth, persistence, file storage, search) that are not visible from the package surface. Architecture fit is high only for a GovTech participation product and low for anything else.

Integration feasibility. Moderate-to-poor as an embedded dependency, better as an isolated service. Historically this lineage is Symfony/Doctrine-oriented; if the package is now Laravel-native, confirm the service provider, config publishing, and migration story rather than assuming Eloquent models exist. Expect the core to require a database schema it owns, plus likely external services (search indexing, object storage, map/tile services, mail). Embedding it inside an existing Laravel app means accepting its schema and its request lifecycle. A strangler-style sidecar deployment (run DEMOS Plan as its own application, integrate over HTTP/events) is materially less risky than in-process integration.

Technical risk.

• License — highest-severity item. GitHub reports NOASSERTION, meaning no recognised standard license was detected. For a public-sector-adjacent codebase this is frequently EUPL-1.2 or a bespoke/dual arrangement, but it must be cleared by legal before any code is read into our repository. Treat as a hard gate.
• Maturity signal. 11 stars indicates a product codebase published for transparency/collaboration by its vendor, not a community-maintained library. Expect vendor-paced releases and thin third-party documentation.
• Coupling and surface area. Large domain models with weak public API boundaries are expensive to upgrade and hard to test in isolation.
• Compliance surface. GDPR/DSGVO handling of citizen submissions, retention rules, and accessibility obligations (BITV) are inherited, not optional.
• Hidden runtime dependencies. Search, GIS, queue workers, and file storage are likely required for a faithful deployment.

Key questions. (1) Exact license and whether derivative/closed redistribution is permitted. (2) Framework reality: Symfony, Laravel, or framework-agnostic — and what is the supported PHP version matrix? (3) Is this a standalone application, a bundle requiring a host app, or a genuine package with a stable public API? (4) What are the hard runtime dependencies (DB engine, PostGIS, Elasticsearch/OpenSearch, Redis, S3)? (5) Test coverage and CI status, and release cadence over the last 12 months. (6) Is there a documented HTTP/API boundary we can integrate against instead of embedding? (7) Is commercial support available from demos-europe, and on what terms?

Integration Approach

Stack fit. PHP is compatible with our runtime, but framework and ORM alignment is the real test. If the core is Doctrine-based and we are Eloquent-based, do not attempt to bridge ORMs inside one process — that path produces dual-session, dual-migration and transaction-boundary problems that surface only in production. Prefer runtime separation: DEMOS Plan owns its schema and lifecycle, our application owns identity and presentation.

Migration path. Sequence as a strangler, not a lift-and-shift:

1. Spike (2–3 weeks): license clearance, then stand the upstream application up in a container with its documented dependencies, and exercise one end-to-end procedure with a statement submission. This is the cheapest way to discover the real dependency graph.
2. Boundary definition: identify the minimal contract — procedures, statements, participants, status transitions. Publish it as an internal API or event contract we own.
3. Sidecar deployment: run the core as a service behind our gateway; integrate via API/events; keep our UI where differentiation matters.
4. Selective extraction (optional, later): only if a specific domain object must live in-process, extract it behind an anti-corruption layer rather than importing the whole core.

Compatibility. Pin PHP and DB versions explicitly against the upstream matrix; verify PostgreSQL/PostGIS and search-engine versions, because geo and full-text features are usually version-sensitive. Confirm migration tooling can run against a schema we do not control, and that our deployment tooling can handle two release cadences. Check whether upstream requires a specific web server or queue topology.

Sequencing. License → architecture spike → boundary contract → sidecar deployment → UI integration → hardening. Do not start UI work before the boundary contract exists; the temptation to reach directly into the core's schema is the main failure pattern here.

Operational Impact

Maintenance. We inherit the upgrade burden of a full application, not a library. Upstream is a product team shipping features for its own customers; breaking changes will track their roadmap, not ours. Budget a standing allocation (realistically 10–20% of one engineer) for version tracking, security patching, and dependency drift, plus quarterly rehearsal of an upgrade in staging.

Support. No stated commercial support in the repository metadata. Confirm whether demos-europe offers SLAs; otherwise our escalation path for a blocking defect in domain logic is a public issue tracker with a small audience. That is acceptable for an internal tool and risky for a citizen-facing statutory process with legal deadlines.

Scaling. Designed for municipal scale — hundreds of procedures, thousands of statements, bursty traffic around publication deadlines. That is likely sufficient for our targets, but the monolith limits horizontal scaling: expect to scale vertically and by read replicas, and to offload search and file serving. Load-test the statement-submission path and the document-export path specifically, since those are the usual bottlenecks.

Failure modes to design for. Schema migrations owned by another team arriving on their schedule; search-index drift after failed reindex jobs; object-storage or map-tile dependency outages degrading pages; role/permission divergence between our identity provider and the core's own role model; queue backlogs delaying notification mail during deadline spikes; and silent data-model changes across minor versions. Each needs an owning runbook and an alert.

Ramp-up. Steep. Expect 4–8 weeks before a senior engineer is productive: German domain vocabulary (TöB, Bauleitplanung, Stellungnahme), statutory process semantics, a large schema, and non-obvious role rules. Onboarding material should be written by us, not assumed from upstream docs. Plan for one named owner to hold this knowledge and treat bus-factor-one as an accepted, documented risk for the first two quarters.

Overall. Viable as the engine of a participation product, provided the license clears and we integrate as a separated service with a contract we control. Not advisable as an embedded dependency inside an existing Laravel application, and not advisable at all before legal sign-off on NOASSERTION.