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...
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...