ASP.NET MVC DDD: зачем повторять один и тот же код 3 раза?
Подходов на самом деле множество,а  возможных реализаций этих подходов еще больше. В зависимости от задачи подход может отличаться. Поэтому надо исходить из задачи.
Добрый день!
Верным является такой подход, который решает поставленную задачу эффективно, быстро и просто. Моя деятельность связана с проектами по автоматизации бизнес-процессов заказчиков. В таких проектах лучше делить всю логику на несколько слоев: слой представлений (в частности, приложение на ASP.NET MVC, WPF, WinForms), слой бизнес-логики (отдельная библиотека, class library), слой доступа к данным (тоже отдельная библиотека).  
Опишу пример.
В одном из своих личных проектов на ASP.NET используется как раз разделение логики на слои. Есть несколько проектов: MyApp.MVC, MyApp.DAL, MyApp.BL. Соответственно, общая схема работы такая: в контроллерах слоя MyApp.MVC идет обращение к методам из слоя MyApp.BL (слой бизнес-логики). Если методу из слоя MyApp.BL нужно поработать с данными БД, то он уже обращается к методам слоя работы с данными (MyApp.DAL). Слой MyApp.DAL уже непосредственно вытаскивает/добавляет/изменяет/удаляет данные. При этом слои не знают о конкретных реализациях методов, т.к. все базируется на интерфейсах и инверсии зависимостей (DI и IoC-контейнере, в частности - Ninject). В итоге что мы получаем:
1. Разделение ответственности (каждый делает только то, что ему нужно, т.е. каждый выполняет свою задачу).
2. Легкость сопровождения (нужно изменить логику выборки данных - например, изменить SQL-запрос. Все изменения коснутся только слоя MyApp.DAL, другие слои в этом случае менять не нужно и им будет "по барабану", что происходит внутри слоя MyApp.DAL).
3. Расширяемость компонентов (здесь я имею в виду, что можно взять слой MyApp.DAL и включить его в другое приложение).
4. Наглядность (код более чистый и последовательный).
Я уверен, что это не "панацея", и в других типах проектах (например, игры? сложные математические модели?) такая архитектура может принести больше вреда, чем пользы (как пример, "продирание" через интерфейсы).