Reference
Plain-English definitions of the software-architecture vocabulary HexPatrol enforces — bounded contexts, ports and adapters, dependency rule, and more. Always-on hexagonal architecture enforcement and auto-correction.
A concrete implementation of a port — the outer-world translation layer that lets a hexagonal application talk to a database, message bus, or third-party API.
In HexPatrol
HexPatrol reads your GitHub Actions run, then a Postgres adapter turns it into scan history rows; swapping it for an in-memory adapter during tests requires zero domain-layer changes.
See FAQ: How does HexPatrol enforce ports and adapters at the import-graph level?
A cluster of domain objects treated as a single unit for writes, with one root enforcing every invariant.
In HexPatrol
In the scans context, one `Scan` aggregate owns its findings, status, and timestamps — any mutation goes through the aggregate root, never by editing a finding directly.
The single entity inside an aggregate that outside code is allowed to hold a reference to; everything else is reached through it.
In HexPatrol
`ScanRun` is the only object the application layer ever imports from the scans aggregate — corrections, summaries, and findings are reached through it.
Translation code that sits between your model and an external system, keeping the foreign model’s vocabulary out of yours.
In HexPatrol
HexPatrol maps GitHub’s `check_run.conclusion` values into the scanner’s own `pass | warn | fail` enum so the domain never imports `neutral` or `cancelled` literals.
The thin layer that orchestrates use-cases by calling domain objects and ports — it has no business rules and no infrastructure.
In HexPatrol
HexPatrol's `RunScanUseCase` loads the repo config, asks the scanner port to fetch results, then asks the scans repository port to persist — no business logic, no HTTP.
A class or function that implements a specific use-case by coordinating domain objects and external ports.
In HexPatrol
Each `Run…UseCase` is an application service: a single entry point, a clear outcome, and no state of its own beyond what's passed in.
Continuous, automated checking that code and dependencies still respect the architectural rules the team agreed on.
In HexPatrol
On every commit, HexPatrol re-validates the dependency rule and port/adapter boundaries; a layer violation is reported and patched before the PR is merged.
See FAQ: What does "architecture enforcement" actually mean in a CI pipeline?
A boundary inside which one model is consistent and one team owns the language — every other context translates in and out, not invades.
In HexPatrol
The `catalog` bounded context owns `Product` in the product sense, while the `fulfillment` context translates it into a `ShipmentItem` — HexPatrol draws the boundary on your dependency graph.
See FAQ: How does HexPatrol decide where one bounded context ends and another begins?
The diagram of every bounded context in a system and the relationships (Customer-Supplier, Anti-Corruption Layer, Shared Kernel…) between them.
In HexPatrol
HexPatrol renders the context map from your real import graph: each detected cluster becomes a context, each cross-context edge shows where you need a translation layer.
The part of the system that is the reason it exists — the model that delivers competitive advantage and so deserves the most investment.
In HexPatrol
For HexPatrol, the scanning engine and its finding model is the core domain; the user-management boundary is supporting and receives proportionally less modelling effort.
Source code dependencies may point inward (toward the domain) but never outward (toward infrastructure or UI); the inner layers know nothing about the outer layers.
In HexPatrol
HexPatrol fails the build the moment a file in `domain/` imports anything from `infrastructure/` — and emits the auto-correction patch that flips the call site instead.
See FAQ: Why is the dependency rule "inward only" so important?
The business the software serves — the rules, processes, and language that exist whether or not there is code for them.
In HexPatrol
HexPatrol’s domain is "scan a repo, find boundary breaks, repair them"; the domain layer models those concepts, not GitHub Actions or Postgres.
A statement that something happened in the domain, published so other parts of the system can react without being coupled to the producer.
In HexPatrol
When `ScanCompleted` is published, the corrections aggregate decides whether to enqueue a patch PR — no direct call, no shared state, just the event.
The innermost layer of the architecture — entities, value objects, domain services, and the rules that govern them, with no knowledge of frameworks.
In HexPatrol
HexPatrol's `domain/` folder imports zero infrastructure symbols; you could delete every adapter and the domain still type-checks and unit-tests green.
A stateless operation in the domain layer that does not belong on any single entity — typically a calculation or a policy.
In HexPatrol
`LayerBoundaryPolicy.evaluate(from, to)` lives in the domain service folder: it asks "is this dependency allowed?" without knowing how violations are reported.
Also called "ports and adapters": an architecture that puts the application at the centre and isolates every external system behind a swappable adapter.
In HexPatrol
HexPatrol itself is hexagonal — the scanning engine sits at the centre with ports for source-code fetching, finding storage, and PR creation; each port has concrete adapters per provider.
See FAQ: What is hexagonal architecture, and how is HexPatrol itself an example of it?
The outermost layer holding adapters, frameworks, drivers, and any concrete technology — the application layer talks to it only through ports.
In HexPatrol
HexPatrol's `infrastructure/postgres/` adapter implements `ScanRepositoryPort`; nothing outside that file imports `pg` or `prisma`.
Any dependency edge that crosses a layer the architecture forbids — for example, a domain type importing an adapter, or an outer layer knowing an inner implementation detail.
In HexPatrol
When a new file under `domain/` starts importing from `@/infrastructure`, HexPatrol flags it as a layer-boundary violation, attributes the offending import line, and emits a patch that moves the call behind a port.
A layering variant of hexagonal architecture that places domain at the centre, application around it, and infrastructure on the outside — with strictly inward dependencies.
In HexPatrol
HexPatrol visualises its modules as onion rings: at the core the domain model, then application services, then in-process ports, then concrete adapters on the outside.
An interface declared by the application that an external system must implement to be usable — the application owns the contract, not the infrastructure.
In HexPatrol
`ScanRepositoryPort` is declared in the application layer; the Postgres adapter implements it, and the in-memory test double implements it — the domain never knows which is wired in.
See FAQ: What is a "port" in HexPatrol — and who owns the contract?
The whole arrangement: the application declares ports (interfaces) it needs, and adapters implement them — swapping infrastructure becomes a wiring change, not a code change.
In HexPatrol
Switching HexPatrol from GitHub to a generic Git host is a new adapter plus a wiring line in the composition root — no domain or application code changes.
An interface that reads and writes aggregates as if they were in-memory collections, hiding the storage mechanism from the domain.
In HexPatrol
`ScanRepository.findByRepo(repoId)` returns scanned aggregates the same way regardless of whether they came from Postgres, a fixture, or a remote service — the call site never imports `prisma`.
See FAQ: How does HexPatrol use the repository pattern without leaking Prisma?
A small subset of the domain model two bounded contexts agree to share deliberately, with joint ownership and joint tests.
In HexPatrol
A `Money` value object lives in HexPatrol’s shared kernel between the `billing` and `catalog` contexts; both import it from one package, both have tests that must pass on changes.
A coherent slice of the business domain — classified as core (competitive advantage), supporting (necessary but not differentiating), or generic (could be bought off the shelf).
In HexPatrol
HexPatrol tags each detected bounded context as core, supporting, or generic in its context map, so teams can prioritise modelling effort where it pays back.
A vocabulary shared between developers and domain experts inside one bounded context — used in conversations, code, tests, and docs.
In HexPatrol
In the corrections context, "patch", "candidate", and "applied" mean exactly the same thing in Slack, in PR titles, and in the corrections aggregate — HexPatrol flags any drift it finds.
See FAQ: How does HexPatrol detect when the ubiquitous language has drifted?