Business rule or repository implementation rule in Clean Architecture

Question

I'm studying Clean Architecture with python and got into this "problem" of choosing where to implement a rule (that I considered a Business Rule, maybe I'm wrong)

I have 2 Entities

@dataclass
class A:
 bs: List[B]
 id: Optional[str]
 # ...
 def add_b(self, b):
 exists = next((x for x in self.bs if x.utc == b.utc), False)
 if exists:
 # treat
 else:
 self.bs.append(b)
@dataclass
class B:
 utc: Datetime # unique in the same A
 id: Optional[str]
 # ...

I decided to consider A an Aggregate since it would always work with a list of bs (at least that seemed the "right" thing to do after some reading about Aggregates), what would make me have only 1 repository: ARepository and I have this Usecase:

class AddBtoA:
 def __init__(self, a_repo: ARepository):
 self.a_repo = a_repo
 def execute(self, a_id, b_data):
 a = self.a_repo.get(a_id)
 b = B(**b_data)
 a.add_b(b)
 self.a_repo.save(a)

Problem

For each A I'll be adding a new B at a rate of ~5 minutes, so the query will grow big fast. It looks like checking if a B with the same utc already exists would better be done at SQL/Repository level with a SELECT for technical reasons and simplify the A.add_b method to directly append the list, but wouldn't this transfer Business Logic to an outer layer?

Maybe I shouldn't consider A an Aggregate and work with B separately and change the way I implemented my Repository/Usecase?

Or this check shouldn't even be considered a Business Rule? I know this is a more "abstract" question, but can't really see thought it.

Would really appreciate every help and clarification about the ways I could deal with this and if there's others mistakes I could have made since I'm still learning :)

• candied_orange: I kept rereading this until I realized bs means b's as in plural. I wont mention what I thought it was before.
• Filip Milovanović: When people say that a domain object should capture/express a business rule, that doesn't mean that everything that is related to, or follows from, that rule, has to be executed in that object at that exact moment in time. Some of it will be, but not necessarily all. That object just has to capture the policy (or provide ways to express it), the mechanisms that implement it can be elsewhere. It just means that when you write client code using your domain objects, they make it possible, by virtue of their design, for the calling code to express its own logic in terms of business rules. 1/3
• Filip Milovanović: So, telling the code to check for a duplicate timestamp is business logic, what happens in response to the check (high-level decision) is business logic, but how the check is performed isn't, and when exactly is up to you (within the constraints imposed by the needs of the domain). Now, in practice, people would typically just let the DB handle all of that, putting some of the business logic in the DB, because that's often good enough, and you need to ship the product, and so on. 2/3
• Filip Milovanović: If you want to experiment, you could try different things. E.g. do it all in-memory, then reconcile with the DB later at well-defined points in your flow. Or, the high-level business function could make its decision by ultimately calling a stored procedure. Or, encode business decisions in a data structure - a set of instructions to be translated to SQL at some later step (ORMs do this). Or something else. This approach requires you to think deeply, and learn about the problem domain, there are no cookie cutter solutions here - and it could be argued that it isn't always worth the effort. 3/3