# Should my class "data" dependency be a repository, adapter or another pattern?

I have a class called CheckUserUltraSecretInformation that is kind of a Use Case in "clean architecture terms", this class has a dependency that is responsible for retrieving a couple of information from a cache "provider", such as Redis, this is a crucial business rule for this use case, in order for the user to retrieve its "ultra-secret information" the cached information must exist.

since "retrieving the data from the cache" it's a data layer, my first thought was to use the repository pattern, but that implicates that I also have an Entity or a "Domain Model" for this repository, the thing is: although I can picture a "CachedUserInformation" object and its properties I cannot see the CachedUserInformation as an entity, because it's not a "core" object of my application.

I feel like this is more of a rule of the use case than an entity, but I cannot just return an array of data from this "repository".

should I just call it CachedUserDataAdapter and return the CachedUserInformation object?

what are some good approaches for this scenario?

my code:

interface CachedUserDataRepository {
function findByDocument(string $document): CachedUserInformation; } class CheckUserUltraSecretInformation { public function __construct( private CachedUserDataRepository$cachedDataRepository
)
{
}

public function Check(string $document) {$cachedUserData = $this->cachedDataRepository->findByDocument($document);

if(empty($cachedUserData)) { throw new Exception('User Cached information not found, cannot proceed'); } } } class CachedUserInformation { private string$id;
private string \$secretInformation;
}
• Entity is any data object with an identifier, so I think it's completely valid to call it an entity. On other hand being cached or not is just an implementation detail and thus shouldn't be part of the name, unless it carries the cache related properties as well. But that might be better modelled with composition, ie CacheEntry<TEntity>. But anyway that doesn't seem to be your case... May 6, 2021 at 4:32
• what do you mean by "carries the cache-related properties as well"? i think my problem with the repository is that I don't have a good name to call the object with only 2 properties, and that it just makes sense in the context of this use case May 6, 2021 at 4:48
• I mean things like expiration of the cache entry or so, anything that relates to cache. You could call it UserSecretInformation because thats what it seems to carry. It (and any entity really) is and should be completely unaware of its lifespan and persisting strategy, if any exists at all. So what if one day you stop caching theese things? You go and rename it to NonCachedUserInformation or what? If the entity only lives in the domain of the cache, then this may be better communicated by sharing a namespace with the cache. May 6, 2021 at 5:04
• In the end software code has to perform a task, be understandable to humans, and preferably be flexible so it can be altered or expanded. When I read your question, I see a lot of buzzwords, but to be honest, I have no idea what it is actually used for. I cannot test it and the title of your question does not describe what the code does either. What's here to review? May 6, 2021 at 13:23