use-cases

name	use-cases
description	Rules for writing use cases in hexagonal architecture. Use this when creating or modifying or reviewing a use case / application service class or function.

Use Cases

A use case orchestrates the domain to fulfil a single user-facing or system-facing intention.

Responsibilities

Use cases implement a single task a user is trying to do, and implementing the business rules around it. They should implement a WHOLE task and NOTHING BUT the task. The name of the usecase should reflect what a user is trying to do, not what the system does.

To do this they:

• Retrieve domain objects via outbound ports.
• Call domain logic on those objects.
• Persist changes via outbound ports.
• Return a result to the caller (inbound adapter).

Rules

• One use case = one intention. Keep them narrow.
• Contain no business rules — those belong in the domain. (But be loose on this if the repo doesn't have a solid domain layer).
• Contain no infrastructure concerns (HTTP, SQL, queues, etc.) — those belong in adapters.
• Depend only on ports (interfaces), never on concrete adapter implementations.
• Accept and return simple value objects or domain types — not framework-specific types.

Anti-patterns to avoid

• Putting validation logic that belongs in the domain inside a use case. (But be loose on this if the repo doesn't have a solid domain layer).
• Directly instantiating infrastructure clients or repositories. There should be no instantiation of anything accept domain objects.
• Handling multiple unrelated intentions in one class/function.

Testing

Should be tested with unit tests that mock out all of the adapters that are used, so only the use case and domain objects are real objects.