Dedicated interface for business logic

[n0tm]

Hello! There is example code for translation use case in your repository. In internal/usecase/interfaces.go you created the Translation, TranslationRepo, TranslationWebAPI interfaces. I completely agree with the TranslationRepo, TranslationWebAPI interfaces, they are technical implementations, so it makes sense to dedicate an interface to them so they can be overridden. But I don’t quite understand, is it really necessary to allocate an interface for the domain UseCase/Service? Vaughn Vernon, in the book Implementing Domain-driven Design, writes that domain-specific implementations of services, or in your case, use cases, do not have to be allocated to interfaces; moreover, he writes that the approach without selecting an interface for domain-specific services is more convenient because domain services have a final implementation and there is no case when they could be replaced. This does not affect testing, because you would rather test useCase or Service Unit tests, and controller integration tests (in your repository this is the case and I completely agree with this)

I opened this issue because my colleagues treat your repository as a doctrine, but when I asked about the benefit of creating this interface, no one could answer why, but they believe that you wrote it for a reason. Therefore, I wanted to clarify this point with you, maybe I don’t see some underwater stones...

[soltanoff]

Hi!

You are right, defining an interface for a domain UseCase/service is not strictly necessary if you have a single implementation and no need for overriding. It is an architectural decision that may be overkill in simple cases, but brings additional benefits in terms of clarity and potential flexibility in more complex systems.

In this repository, the interface for a domain UseCase/service defines an explicit contract, which can be useful for clarity and documentation of business logic. Even if there is currently only a single implementation, the interface helps to clearly indicate what operations are available.

For example, on one of our projects, we also came to the conclusion that it is not worth hiding UseCase/service behind interfaces if you can depend on them directly.

I hope I helped you figure it out.