A testing strategy for a domain-centric architecture (e.g., hexagonal)

I’ll propose a testing strategy for the hexagonal architecture.

Hexagonal architecture

The hexagonal architecture and the clean architecture are domain-centric architectural patterns. They’re adaptable to your needs; even simple apps like command-line tools benefit from centralizing the domain (to separate the I/O from the actual algorithm).

Photo by LekoArts on Unsplash

Here’s what you need to know:

• The main principle is that the app (e.g., a bounded context) is comprised of a ‘domain’ (core) and an ‘infrastructure’ (I/O). The ‘domain’ represents the business domain (higher-level code); the ‘infrastructure’ means the technology (lower-level code).
• The domain should make use of the ubiquitous language; it’s mostly comprised of use cases (business commands and queries), entities (business objects), value objects, and ports (domain boundaries). Entities are not ORM objects or DTOs (e.g., view models, serializers). Entities and value objects have their logic.
• The infrastructure comprises primary/driving adapters and secondary/driven adapters. Primary adapters (i.e., entry points or delivery mechanisms) are how users and other systems interact with your app (e.g., a web…