With DDD, it's all about the domain concepts and relationships (which are NOT rdbms relationships). OOP doesn't mater either, as it's a technical approach while you're using a business (domain) approach. However, you'll be using OOP implicitely because it's the nautral way to model a domain.
I don't know your domain, but based on how you described the problem, I think there is not much DDD there, but the old CRUD mindset masked by DDD terminology. IT doesn't look that you have identified the relevant bounded context and aggregate roots (AR). Then, what can those entities do (the behaviour)? How they are used (the uses cases they're involved)?
WHen you do DDD, you let the domain tell you which are the objects and how they interact with each other. An AR can 'point' to another AR via an Id, however the context and the use cases it matters a lot. And you can have multiple AR modelling the same concept but in different contexts, so there isn't always just one Account AR usable everywhere.
Take your time and forget about OOP, ORM, rdbms etc. Focus only on the Domain to properly understand the concepts (they can be tricky!) and their relationships. The resulting code will be good OOP and more importantly good modelling. Worry about persistence and rdbms after that.
Edit
Based on OP and the gist from the comment, I think (I can only guess since I don't now the domain) that it's a use case for Lead (Table) so, If there are no other relevant details, I'd have a service or similar which will take the Lead and IEnumerable to do the behaviour. You ask the Accounts repository for the accounts for the lead, providing a matching criteria (area code and campaign_id).
As a rule of thumb, I suggest to try and dissect these concepts and try to reformulate their relationships until you're certain you've understood the right relationship.