Job board: Reference architecture

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.yaml are 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.