Значит у вас приложения не были под нагрузкой или они слишком простые, чтобы тормоза могли возникнуть.
А тормоза возникают вот так:
Делается модель (набор классов), она отображается в БД. При выполнении операции объекты начинают обращаться к связанным объектам, которые достаются с помощью Lazy Load. Поэтому если пишешь foreach цикл по вложенным объектам у тебя получается SELECT N+1. Причем цикл написать очень просто если работает несколько человек.

Пример.

Первый программист пишет метод:

class Order
{
    public void ProcessOrder()
    {
        if(this.Customer.Age < 18) //Тут кастомер загружается LL, вроде ниче страшного
        {
            //Some logic
        }
    }
}

Второй программист потом пишет такой код:

class Manager
{
    public void BatchProcessOrders()
    {
        foreach(Order o in this.Orders)
        {
            o.ProcessOrder(); //SELECT N+1, только об этом узнать нельзя пока не заглянешь внутрь
        }
    }
}

Самая большая проблема когда такой код в разных слоях.

Но вот проблема найдена, но как её исправить? Обычно тут вспоминают агрегаты. Говорят что будет Order грузится сразу с Customer. А потом из-за аналогичных проблем Order должен грузиться вместе с OrderLines.
А дальше банальный вывод списка 100 ордеров начинает тянуть мегабайт данных. При мало-мальской нагрузке падает все.
Далее, если есть голова на плечах, люди просто сносят DDD, делают anemic модель и управляют загрузкой данных. А вот если головы нет, то начинается политики оптимизации Hibernate, подсовываемые через AOP, CQRS, NoSQL, гигабайтные распределенные кеши и прочая гадость.

Для того чтобы не было таких проблем изначально надо соблюдать простое правило: бизнес логика должна явно управлять загрузкой (кешированием) данных и тянуть как можно меньше данных из базы. Это, к сожалению многих «архитекторов», ломает всю идею DDD.