Defines a reference job-board architecture with separate vacancy, employer, candidate, search, application, moderation, communication, and analytics boundaries plus the identities and events joining them.
Package status: reference context ready for human review. The contract and test scenarios are complete, but no claim is made that an adopting implementation has passed them.
Decision
Use a transactional core for accounts, vacancies, and applications; build search as a versioned projection and communications as idempotent reactions. Keep employer and candidate visibility policies centralized and applied to serving, search, export, and analytics.
Scope
- Actors, core aggregates, module boundaries, main workflows, search projection, moderation, applications, notifications, analytics, storage, security, and operations.
- A multi-sided job marketplace from vacancy publication through candidate application.
- Reference boundaries that can begin in a modular monolith and evolve from evidence.
Outside this block
- Country-specific employment law, payroll, background checks, or a complete recommendation model.
- Sharing candidate personal data merely because an employer account exists.
Contract
- Candidate, employer organization/member, vacancy, resume/profile, application, conversation, moderation case, and consent/preference have distinct stable identities.
- Vacancy publication requires ownership, content validation, moderation policy state, location/remote model, active interval, and visibility.
- Search indexes only eligible current projections and carries source version, visibility, and moderation state.
- Application creation snapshots the vacancy and candidate intent needed for later interpretation and is idempotent.
- Employer access to candidate data follows vacancy/application relationship and explicit product policy, with auditing and revocation.
- Messages and analytics consume committed events and cannot become the authority for application or vacancy state.
Implementation guidance
- Suggested modules: identity, organizations, candidate-profile, vacancy, applications, search-projection, moderation, communications, and analytics.
- Use an outbox from transactional modules and an idempotent inbox in projections.
- Treat resumes and attachments as private objects with separate file versions and access checks.
- Version taxonomies for profession, skills, location, employment type, and salary currency without rewriting historical applications.
Failure handling and safeguards
- If search projection lags, show freshness behavior and keep direct vacancy state authoritative.
- If moderation retracts a vacancy, remove it from discovery promptly while preserving authorized application history.
- If an event is duplicated or reordered, projection version guards prevent regression.
- If employer membership is revoked, cached, exported, messaging, and direct-object access are denied under the revocation policy.
Verification and operations
- Measure publication lead time, eligible-to-index lag, search success, application completion, duplicate application, moderation actions, unauthorized denials, message delivery, and projection reconciliation.
- Run synthetic candidate/employer isolation journeys and search eligibility probes.
- Review module coupling before extracting services.
The executable-looking examples in this package are fixtures and acceptance contracts. Run
python tools/validate.py from the collection root to check package structure and metadata; then
implement and execute the scenarios in the target repository.
Adoption assumptions
- Names and numeric values in
example.yamlare an adoption profile, not universal defaults. - The adopting team must map actors, data classes, error vocabulary, and ownership to its system.
References
- No external normative source is required; this package defines a project decision.