遵循六边形架构与DDD原则，用例/应用服务需接口与实现吗？接口放哪？

Great question—this is a common point of confusion, and the answer boils down to balancing principles with practicality. Let’s break it down:

1. Do you need an interface (like IDeleteVideo) and an implementation (like DeleteVideoImpl)? #

No, there’s no hard rule in either Hexagonal Architecture or DDD that mandates splitting every use case into interface + implementation. If your use case logic is stable, straightforward, and unlikely to need alternative implementations (e.g., no need for mock versions in testing, no planned future variations of the delete logic), sticking with just a concrete implementation class is totally acceptable.

That said, there are scenarios where adding an interface makes sense:

• Testability: If you need to mock the use case in higher-level tests (though in practice, you’ll often mock external dependencies of the use case, like repositories, instead of the use case itself), an interface makes this easier.
• Future flexibility: If you foresee potential changes to the use case’s execution (e.g., switching from immediate deletion to soft deletion + async cleanup), an interface lets you swap implementations without changing the code that calls the use case.
• Dependency inversion: Following the Dependency Inversion Principle, the interface acts as a "port" in Hexagonal Architecture. External adapters (like API controllers) depend on this port instead of the concrete implementation, keeping your core logic decoupled from external concerns.

2. Where should the use case interface live? #

If you do choose to define an interface, it belongs in the application layer, not the domain layer. Here’s why:

• Use cases (application services) are part of the application layer—their job is to coordinate domain logic (e.g., triggering domain events, calling aggregate methods) with external services (e.g., repositories, notification services).
• The domain layer should be completely independent of application concerns. Putting the use case interface in the domain layer would introduce a dependency from the core domain to application-level logic, which violates the boundary rules of both DDD and Hexagonal Architecture.
• In Hexagonal terms, this interface is a driving port: it defines the way external actors (like API controllers) can trigger the use case. Driving ports are always defined in the application layer, with their implementations also residing there.

3. What do the principles actually mandate? #

Neither DDD nor Hexagonal Architecture requires interface/implementation splits for every use case. Their core focus is on:

• Clear boundaries: Separating the domain layer from application and infrastructure layers.
• Dependency direction: Ensuring external layers depend on the core, not the other way around.
• Isolating domain logic: Keeping business rules pure and free from infrastructure or application-specific code.

If a concrete implementation class satisfies these goals without an interface, that’s perfectly aligned with the principles. The interface is a tool to enforce these goals when needed, not a requirement in itself.

内容的提问来源于stack exchange，提问作者Mr. Mars