I have a fairly big database, about 80 tables or so. So I've decided to separate the tables into bounded context instead of having all 80 tables in 1 big edmx file.
So I have bounded contexts like Sales, Customers, etc.
I have my main customer table within my Customers edmx file. However, I also need to access certain fields, not all, but 1 or 2 fields (e.g., I just need customer name, instead of the whole customer object/table) from the customer table from the Sales edmx context.
Do I have to add the whole customer table into the Sales edmx file? What's the best practice for this scenario?
There are a couple of underlying issues with this approach (IMO):
EF, like any ORM, falls into the persistence concern. As such it should not be interfering with how you structure your domain model. The fact that you have all your entities persisted in what sounds like one persistence store may be an indication that your bounded contexts are overlapping or are non-existent.
Trying to move to a better structure is not a bad thing :) --- however, as Mark Oreta stated, I probably wouldn't bother with the EF structure.
The primary issue you are running into is caused by trying to read from your domain model. This seems to crop up all too often in systems and it makes things rather difficult. Lazy-loading is the direct result of exactly this. When you read you should, ideally, be using a query layer with access to a query store (may be the same database) that is optimized for reading. In your example you need a denormalized customer name in your sales domain. That is fine. Trying to get that by reading your domain model and then trying to pull in data from a domain model in another bounded context is what is causing you the pain.
If you go down the route of splitting your data then you will need to keep it split.
Although the data from various BCs may all be in the same store you should think of your data as though each BC has its own database. Sometimes I have a single project with various concerns (layers to some) in different folders/namespace (.NET here). It should be possible to split out those concerns into separate assemblies on a whim. So they should not be too tightly coupled. The same goes for this data structure you are attempting to split. You should in essence be able to split out the relevant BC data to a separate database. The mechanisms for getting data across the BCs is another matter and I guess if that cannot be addressed you may find it tough going.
Although I don't think that identifying BCs from the data side may be best idea it is certainly a step in the right direction :)