При работе с моделями предметной области и ПОСТЕПЕННО классами, куда запросы идут?

Объекты области должны быть независимы от устройства хранения данных, необходимо использовать шаблон Repostiory или ДАО для сохранения объектов. Тем путем Вы осуществляете разделение проблем, сам объект не должен знать о том, как это хранится.

Идеально, это была бы хорошая идея вставить конструкцию запроса репозитория, хотя я буду использовать ORM внутри там.

Вот определение Martin Fowler Шаблона Репозитория.

Объекты являются "единицами" домена. Репозитории и сервисы ссылаются на них, не наоборот. Думайте об этом этот путь: Вы несете DMV в своем кармане?

OrderItem не совокупный корень; это не должно быть доступно через репозиторий. Его идентификационные данные локальны для Order, значение Order всегда будет в объеме при разговоре о OrderItems.

Трудность нахождения дома для запросов приводит меня думать о сервисах. В этом случае они представили бы что-то о Order это трудно для Order самостоятельно знать.

Объявите намерение в доменном проекте:

public interface ICheapestItemService
{
    OrderItem GetCheapestItem(Order order);
}

public interface IInventoryService
{
    IEnumerable<OrderItem> GetOutOfStockItems(Order order);
}

Объявите реализацию в проекте данных:

public class CheapestItemService : ICheapestItemService
{
    private IQueryable<OrderItem> _orderItems;

    public CheapestItemService(IQueryable<OrderItem> orderItems)
    {
        _orderItems = orderItems;
    }

    public OrderItem GetCheapestItem(Order order)
    {
        var itemsByPrice =
            from item in _orderItems
            where item.Order == order
            orderby item.Price
            select item;

        return itemsByPrice.FirstOrDefault();
    }
}

public class InventoryService : IInventoryService
{
    private IQueryable<OrderItem> _orderItems;

    public InventoryService(IQueryable<OrderItem> orderItems)
    {
        _orderItems = orderItems;
    }

    public IEnumerable<OrderItem> GetOutOfStockItems(Order order)
    {
        return _orderItems.Where(item => item.Order == order && !item.InStock);
    }
}

Этот пример работает с любым поставщиком LINQ. С другой стороны, проект данных мог использовать NHibernate's ISession и ICriteria сделать грязную работу.

Поскольку я понимаю этот стиль дизайна, Вы инкапсулировали бы запрос в методе OrderItemRepository (или возможно более соответственно OrderRepository) объект, ответственность которого состоит в том, чтобы говорить с DB на одной стороне и возвратить объекты OrderItem с другой стороны. Репозиторий скрывает детали DB от потребителей экземпляров OrderItem.

На уровне служб.

Я утверждал бы, что не имеет смысла говорить о "Порядке, который содержит только OrderItems, которые не находятся в запасе". "Порядок" (я предполагаю), представляет полный список того, что заказал клиент; при фильтрации того списка, Вы больше не имеете дело с Порядком по сути, Вы имеете дело с фильтрованным списком OrderItems.

Я думаю, что вопрос становится, хотите ли Вы действительно рассматривать Заказы как Совокупный Корень, или хотите ли Вы смочь вытащить произвольные списки OrderItems из Вашего уровня доступа к данным также.

Вы сказали, что объекты фильтрации после того, как они возвратились из базы данных, были бы слишком дорогими, но если Вы не насчитываете сотни или тысячи OrderItems для каждого порядка (или существует что-то еще особенно интенсивное о контакте с большим количеством OrderItems), можно пытаться оптимизировать преждевременно и делать вещи более трудными, чем они должны быть. Я думаю, можно ли оставить Порядок как совокупный корень и просочиться доменная логика, модель будет более чистой для работы с.

Если это - действительно не случай, и необходимо просочиться база данных, то можно хотеть рассмотреть наличие отдельного репозитория OrderItem, который обеспечил бы, запросы как "дают мне все OrderItems для этого Порядка, которые не находятся в запасе". Вы затем возвратили бы тех как IList<OrderItem> (или IEnumerable<OrderItem>), так как они не полный Порядок, а скорее некоторый фильтрованный набор OrderItems.