Query criteria for repository.

[spirosoik]

Hi guys,

I have query with three params and I want to make this triplette a Criteria object where do you thinks is the best place to add the criteria object in order to not violate the rules of clean Architecture.

Currently I added in the domain layer. Any other suggestions or better approaches? basically I want to have these params as a POD.

[Trikke]

I'll need some more details on how your example is structured, because it depends on how this Criteria is used. There are cases were it could exist entirely in the Data layer, but also cases where it's part of the Domain.

[spirosoik]

The criteria used in the UseCase which pass them in the repository that's why I added the criteria in the domain layer.

[Trikke]

If you're not storing the Criteria Objects anywhere, and their sole purpose is to bundle those parameters together, i'd say they're fine in the Domain Layer and could be seen as a sort of Data Transfer Object. Once you're doing more than that with them, it's time to re-evaluate their purpose.

Uncle Bob has the following to say on data that crosses boundaries.

What data crosses the boundaries.

Typically the data that crosses the boundaries is simple data structures. You can use basic structs or simple Data Transfer objects if you like. Or the data can simply be arguments in function calls. Or you can pack it into a hashmap, or construct it into an object. The important thing is that isolated, simple, data structures are passed across the boundaries. We don’t want to cheat and pass Entities or Database rows. We don’t want the data structures to have any kind of dependency that violates The Dependency Rule.

For example, many database frameworks return a convenient data format in response to a query. We might call this a RowStructure. We don’t want to pass that row structure inwards across a boundary. That would violate The Dependency Rule because it would force an inner circle to know something about an outer circle.

So when we pass data across a boundary, it is always in the form that is most convenient for the inner circle.

[spirosoik]

Yes that's the case and thanks for the reference @Trikke .

[Trikke]

Just a little side note, i'm not saying this is what you are doing as i have completely no idea of the scope you are working in, but more as a future reference for anyone going through these threads.

This question just reminded me that i sometimes come across developers adding Data Objects just for the sake of bundling some parameters together and having "cleaner code" (ie: less arguments). But as the reference says, data that passes boundaries can just be a number of arguments that are passed through. More classes doesn't equal a better architecture.

[spirosoik]

@Trikke I agree with this one but sometimes is better to use a class or a builder rather than a multiple params. If we remember the Effective's java rules methods or constructors can accept at most 4 params.

[Trikke]

@spirosoik Of course, i just added that little story as a reminder that we as programmers must always think about the scope of what we are building and not create stuff because it looks prettier. And indeed as you stated, there are also valid cases in which a Data Object or a Builder Pattern makes more sense.