UseCase and the dependency rule

[pierreboissinot]

Hi @romainkuzniak ,

Thanks for sharing your interpretation about clean-architecture. I'm still learning about Clean Architecture so forgive me if I'm wrong but I think the dependency rule is violated in your UserCase using the Security annotation of Symfony. The use case becomes framework dependent.

Source code dependencies must point only inward, toward higher level policies

Rober C.Martin in his book Clean Architecture.

After a few research about "how about security in Clean architecture", I found this answer:

Security is an application specific concern, it belongs to the interactors. The controllers would access the current user's credentials and pass that information to the interactors. The interactors would use an authorization service to ensure that their particular interaction was authorized. The business objects wouldn't know anything about it.

https://groups.google.com/d/msg/clean-code-discussion/wHzmboOEHzo/3bO-r_dXpbAJ

What do you think ?

[romainkuzniak]

Hi thank you for your message.

You are currently looking for a library that help us to implement the clean Architecture.
It's not how we do Clean Architecture. It's an helper.
If you want to watch an example (quite old), here it is: https://github.com/romainkuzniak/symfony-clean-architecture,
Especially this class for the usage of annotations https://github.com/romainkuzniak/symfony-clean-architecture/blob/master/src/BusinessRules/UseCases/Sprint/CloseSprint.php
In this case, it's the transaction one. (I don't have example with security, but it's the same technic)

So, let's go back to your question, when we write the use case, we add a security annotation related to our library (not the one from Symfony), to avoid security checks code within the method, to be more focus on the functional rules. Same for transaction, cache and so on (the purpose of the library)
Within the library we're using Symfony.
But let say, if we would like to use another tool, we could, we just have to change it in the library, but not the annotation used within the use case class.

So this annotation, from the library provide abstraction to the security check mecanism.
So we're not violating dependency inversion:

• the use case relies to an abstract annotation
• the services attached to this annotation can change without changing the use case.

More info here https://fr.slideshare.net/RomainKuzniak/design-applicatif-avec-symfony-zoom-sur-la-clean-architecture-symfony-live

Hope it helps.