Mixing technical integration data with domain attributes in a hexagonal architecture use case model

17 hours ago 1
ARTICLE AD BOX

I’m working on a system designed with Hexagonal Architecture.

In one use case, I need to load a domain entity together with additional data obtained from an external provider through a port. The external provider returns both:

data that is clearly part of the business domain (used in business rules), and

technical metadata required later by an outbound adapter to execute an operation.

For performance reasons, both pieces of information come from the same external request, so splitting them into multiple calls is not an option.

To model this, I created a use-case-specific object that combines:

the core domain entity,

some additional domain attributes derived from the provider response

the technical metadata needed later for integration.

Conceptually something like:

class OperationModel { DomainEntity entity; DomainAttribute attribute; IntegrationMetadata metadata; // only used by adapters }

The metadata does not participate in business rules and exists only to allow the infrastructure adapter to perform a later call.

My concerns are:

Is it acceptable (from a hexagonal perspective) for a use-case model to carry technical integration metadata alongside domain data?

Is there a recommended pattern for transporting integration data through the application layer without polluting the domain model while still keeping the code ergonomic?

I’m trying to balance: domain purity, performance constraints, and code clarity.

What would be considered a good design in this situation?

Read Entire Article