Should I add a property in domain model just for entity framework?

I'm attempting to synthesize what I've been reading about domain driven design and the entity framework model-first capabilities. I have an existing database, but I ignored that while I created my domain model. I ended up with a Company class and a Person class. In the model, I have no need for a relationship between the two classes. However, I do need a way to get a list of the people at a company. I decided that I would have a GetPeople(int companyId) method on my PersonRepository, so that I wouldn't have to have a Company instance in order to get this list. The classes look like this:

Company Class

int Id

string Name

Person Class

int Id

string FirstName

string LastName

PersonRepository

IEnumerable<Person> GetPeople(int companyId) { ? }

Now to the database/EF part. In the database, I have a basic foreign-key relationship, so the tables look just like the classes above, except that the Persons table also has a Compa开发者_如何转开发nyId field.

Since I haven't added any reference to this database relationship in the domain model, EF has no idea that the classes are related, and so when I go to write the GetPeople method, I can't do this...

public IEnumerable<Person> GetPeople(int companyId) {
   return MyDbContext.Persons.Where(c => c.CompanyId == companyId);
}

...because there is no CompanyId property on the Person class in the domain model. I can always add that property, but then the persistence mechanism is now influencing my domain model, which seems to be what you want to avoid with a model-first approach.

Does adding that property incorrectly intrude on the domain model, or is it not an improper intrusion because it's still just a POCO?

Depending on what you need to accomplish...

You could add an Employees table/object that ties the Company ID and Person ID together.

With that you can get the Employees for a particular Company, or get the Company that a particular Person works for.