#Hexagonal architecture: ports and adaptors

Hexagonal architecture exposes meaningful application interactions and expresses external needs through ports. Adaptors connect those capabilities to technologies. Source dependencies point towards application and domain policy.

#Ports describe capabilities

A port can be an interface, protocol, function or public method. Define it around a meaningful capability. An application call reaches a concrete adaptor at runtime; the application's source depends on its port contract.

#Follow an actual handler

The handler checks admission, loads its target, invokes aggregate behaviour and saves a material change. The surrounding transaction machinery owns commit and receipt bookkeeping. The handler receives ordinary context, command and port values.

Source: set_party_access_state.go

type SetPartyAccessStateCommandHandler struct {
	Admission  ports.Admission
	Repository ports.AuthenticationWriteRepository
}

Read the complete handler and Beto adaptor map. External provider observations are acquired and validated at their owning boundaries before the aggregate transaction applies them.

#Composition and lifecycle

Dependency injection supplies collaborators. Composition roots choose concrete implementations and own their lifecycle. Resolve the graph before workers start; drain workers before disposing of their resources. Clean up partial startup.

An in-memory fake can show which port the handler calls. A real PostgreSQL test establishes transaction and concurrency behaviour. These are different claims with different evidence. Read the composition decision.

Next: CQRS.

Adapted from the architecture reference, with Pharos examples.