In the clean architecture we don't create any dependency in application layer but every instructor use fluentValidation in that layer, isn't that a dependency ?

CodePudding user response：

An app layer's interfaces should avoid dependencies leaking outside the layer. For FluentValidation in particular:

ValidationResult DoSomething(Thing thing);

ValidationResult is a class defined by FluentValidation, and since FluentValidation is a dependency for that app layer the return of a ValidationResult is leaking FluentValidation to another layer.

Instead, the app layer that is using FluentValidation should define its own result which extends no other external dependency. For example:

public class ApiResult // no extension of any other external dependency
{
   public IEnumerable<string> Errors {get; protected set;}
}

so the interface to the app layer would be changed to:

ApiResult DoSomething(Thing thing);

and internally, the app layer can use FluentValidation and map the results from FluentValidation's ValidationResult to ApiResult.

CodePudding user response：

When taking Clean Architecture strict we would have to conclude that such a dependency breaks the Dependency Rule.

On the other hand: "some dependencies we have to marry" as Uncle Bob writes. For example: if you develop based on .NET you also marry the libraries of that framework/platform.

In the end it is a tradeoff decision which has to be taken conscious: what do you value more, the benefit of the independence from any/most third party library in your application layer or the benefit of reusing functionalities others created and maintain.