# Infrastructure and Model Decoupling

## Prevent technology leakage

Common violations include:

- passing framework contexts or HTTP status codes into services;
- writing GORM, SQLX, or raw SQL chains inside business workflows;
- exposing third-party SDK request or response types in domain methods.

## Consumer-owned interfaces

The business or application package defines the capability it needs; infrastructure implements it implicitly. The consuming package should depend on a narrow behavior such as `MessageSender`, `Clock`, or `OrderRepository`, not on a vendor client.

Do not introduce interfaces speculatively. Add one where it protects a real boundary, enables a required alternative, or makes business behavior independently testable.

## Model isolation

Use separate models when contracts differ or evolve independently:

```text
transport DTO -> domain entity <- persistence object
```

- DTOs carry transport validation and serialization metadata.
- Domain entities express business meaning without framework, JSON, BSON, or ORM tags.
- Persistence objects carry database and driver mapping metadata.

Conversion code at these boundaries is intentional duplication. A small application may combine models until independent evolution creates a concrete need; do not force three structures when their contracts are genuinely identical.

Domain types must not import transport, ORM, database, cache, messaging, or vendor SDK packages.