Community architecture and boundary¶
The open-core architecture separates an executable Community foundation from private capabilities added by Enterprise. The dependency follows one direction:
Enterprise → Community
Community never needs Enterprise code to compile, start, or run its workflows.
Publishable components¶
| Component | Role |
|---|---|
| Community backend | Java 21/Spring Boot application with model, persistence, routines, services, APIs, and synchronous execution |
| Community front | Vue/Vite SPA separate from the backend, containing open-edition pages and components |
| Runtime Info | Public contract loaded before login to identify the edition and actually selectable options |
| Documentation | Journeys, data, reference, and troubleshooting tied to the published version |
Backend and front are built separately. The backend repository does not embed
the SPA source or dist; release packaging combines compatible artifacts in a
dedicated step.
Capability discovery¶
The edition is not selected through a generic environment variable. Runtime identity comes from the artifacts and implementations present.
The front reads Runtime Info before mounting the application:
available...lists contain only options executable in the current runtime;...Optionscatalogs may show blocked Enterprise capabilities to explain the upgrade path;- a blocked option never enables an Enterprise call, route, or component in the Community bundle.
This prevents the UI from offering a forecast model or Supply Planning mode that the backend cannot execute.
Functional boundary¶
| Area | Community | Enterprise |
|---|---|---|
| Demand Planning | classical statistical models, sell-out, historical splits, and material-location Planning Book | advanced models and treatments, private AutoFit, sell-in, Sales Orders, collaboration, and advanced aggregation |
| Supply Planning | heuristic engine, fair share, constrained plan, and material-location Planning Book | optimizer, process chain, advanced constraints and models |
| Data | material, location, UOM, sell-out, inventory, network, and production required by Community workflows | documents, costs, finance, GIS, and capability-specific data families |
| Execution | synchronous calls and process history | queues, workers, batch, and distributed execution |
| Security | simple login, hashed password, and basic administration | SSO and advanced policies |
| Experience | Community pages and clearly blocked Enterprise items | private-capability routes, components, and actions |
The data catalog documents the full platform and qualifies contracts that may differ by edition. Effective availability must always be confirmed by Runtime Info and the release documentation.
Persistence and operation¶
The Community backend is designed for relational databases supported by the open edition. Connection setup, schema migration, compatibility, and backup will be published per version; development examples are not a production contract.
Community executions are synchronous. The interface must show acceptance, completion, or failure without assuming a private queue. When an Enterprise capability is missing, the backend must reject the request clearly instead of simulating success.
Extension without reverse dependency¶
Extension points exist only where the core must delegate an optional capability. Enterprise provides the real implementation and may enrich the Community result; it does not replace the core with empty services or a second complete copy of the same process.
This discipline produces three important properties:
- Community remains understandable and executable on its own;
- the private edition reuses shared model, validation, and calculation;
- documentation can explain a common foundation without hiding edition differences.
Continue to the first planning workflow.