[Ep 03] Identifying Our First Services — The Origin Blueprint / HireFlow

Identifying Our First Services

2025-12-05 · back to arc

From actors to boundaries — we translate the briefing into concrete service domains. Each service emerges from responsibility, authority, and clarity, forming the first stable shape of Hireflow’s architecture.

Identifying Our First Services

Now that the actors are mapped, the natural next step is to ask a deceptively simple question:

“What exists in this world?”

Actors show who interacts with the system.
Services define where responsibility lives.

A service is not “a controller” or “a folder” — it is a boundary of authority.
It owns a part of the domain, the data, and the decisions within it.

So we return to the briefing and extract nouns and verbs that hint at areas of responsibility.
Not implementation details — domains of meaning.

From the original briefing, the ecosystem seems to revolve around:

If we squint, these concepts start clustering naturally — as if the system is revealing its own topology.

Let’s process them one by one with WNT’s “calm, deliberate” approach.

1. Identity & Roles

We identified earlier that we have four roles:

This already defines our first service:

Identity Service

Responsibility:

Authority:
Owns everything related to identity.

Reasoning:
Identity is foundational.
Every other service depends on knowing who is acting and what they can do.

So the Identity Service is not optional — it is the gatekeeper.

2. Company & Job Management

Companies create job postings.
Recruiters manage them.
Candidates apply to them.

This gives us a second clear boundary:

Company-Jobs Service

Responsibility:

Authority:
Owns jobs and their lifecycle.

Why separate it?
Because job management is a domain in itself.
It evolves independently from candidates or evaluations.

3. Candidates Service

Candidates are not just entities — they have profiles, histories, resumes, preferences.

Candidates Service

Responsibility:

Authority:
Owns candidate data and its evolution.

This avoids mixing candidate information with job or application information, which is a trap monoliths often fall into.

4. Applications Service

The heart of the hiring flow:
A candidate applies, a recruiter evaluates, a decision is made.

Applications Service

Responsibility:

Authority:
Owns the lifecycle of an application.

This is where business rules grow dense.
Separating applications keeps the rest of the system clean.

5. Notifications Service

Whenever certain events happen — application submitted, recruiter invited — someone needs to be notified.

Notifications Service

Responsibility:

Authority:
Owns outbound communications.

This service listens to events (RabbitMQ in our architecture) and emits notifications.

6. Search Service

Across companies, jobs, and candidates, search becomes an important operational capability.

Search Service

Responsibility:

Authority:
Owns search indexes and denormalized views.

This service does not store source of truth data — it mirrors other domains through events.

7. Gateway

Even though it is not a domain service, the system needs a stable entry point.

Gateway

Responsibility:

Authority:
Owns how the outside world enters the platform.

It is the front door.

8. Timer / Automated Workflows

Timers trigger cleanup routines, periodic evaluations, or automated transitions.
These are orchestrated not inside the services but through scheduled messages.

Workflow Scheduler

Not exactly a “service”, but a mechanism:

Responsibility:

Authority:
Owns temporal events.

This could be implemented with Kubernetes CronJobs, or a lightweight internal scheduler.

Current Map (Early Draft)

By now, the system begins to reveal its natural structure:

This list will evolve.
It always does.
But it already gives us enough clarity to design paths, boundaries, and interactions.

And more importantly:
it gives us confidence that each service has a purpose and a clean responsibility.