If code is what you're struggling with, find the reason it's there. If there's no valid reason to be found, get rid of the code and write code that has a reason to be there. Your question is showing a list of self-inflicted problems caused by the usage of a pattern which might have solved a couple of problems but introduced a lot more, most of them technical ones.

Let me refer to my answer on SO about whether or not DDD is a waste of time: http://stackoverflow.com/questions/810606/is-ddd-a-waste-of-time/810661#810661

This might get you a bit of perspective what DDD is and what it isn't. The TL;DR is that it's not a technical solution but could (not would!) end up in a technical solution of some sort, but it doesn't have to.

The extensive graph fetching might hint at a SELECT N+1 problem through either lazy loading or loops in place which fetch code of related elements. This might be done to be able to produce a projection on the data in-memory. Looking at the class snippet though, I don't see a deep DDD influence there, as the collections otherwise wouldn't have been there.

It might be wise to see whether you actually need to fetch entity instances in a graph at all, as it might be way faster to formulate the projection of the data needed as a linq query over the entities in the model and let the DB do the set production. The resultset can then be fetched into new POCO objects, which are simply flat lists and these are then used in the UI. This is of course read/only data but for a lot of cases this is enough.

If code is what you're struggling with, find the reason it's there. If there's no valid reason to be found, get rid of the code and write code that has a reason to be there. Your question is showing a list of self-inflicted problems caused by the usage of a pattern which might have solved a couple of problems but introduced a lot more, most of them technical ones.

Let me refer to my answer on SO about whether or not DDD is a waste of time: https://stackoverflow.com/questions/810606/is-ddd-a-waste-of-time/810661#810661

This might get you a bit of perspective what DDD is and what it isn't. The TL;DR is that it's not a technical solution but could (not would!) end up in a technical solution of some sort, but it doesn't have to.

The extensive graph fetching might hint at a SELECT N+1 problem through either lazy loading or loops in place which fetch code of related elements. This might be done to be able to produce a projection on the data in-memory. Looking at the class snippet though, I don't see a deep DDD influence there, as the collections otherwise wouldn't have been there.

It might be wise to see whether you actually need to fetch entity instances in a graph at all, as it might be way faster to formulate the projection of the data needed as a linq query over the entities in the model and let the DB do the set production. The resultset can then be fetched into new POCO objects, which are simply flat lists and these are then used in the UI. This is of course read/only data but for a lot of cases this is enough.