На мой взгляд, между паттернами и дизайном вообще нет ничего общего. Я бы сказал, что это две вещи связаны между собой только в голове адептов паттернов и прочих баззвордов.

В разных обсуждениях частенько приводятся аргументы навроде: "Это (не)правильно, потому что это (не)паттерн Х".

Есть некоторые возражения
1. любой паттерн можно прикрутить к самым разным задачам, между которыми вообще нет ничего общего
2. любую задачу можно решить по разному и все эти способы завернуть в один и тот же паттерн
3. к любой задаче можно прикрутить самыме разные паттерны

Скажем, для примера, любой сколь угодно трудный кусок монолитного спагетти-говнокода можно с легкостью завернуть во что угодно, далее, поверх этого винигрета прикрутить ну тот же DI/IOC + composition container (модули и тд). Затем, этого франкенштейна, в свою очередь, можно покрыть говно-тестами, для которых наколбасить говно-моки, задокументировать и даже заюзать в нескольких местах. Не важно, сколько намешано обязанностей и зависимостей, две, три, десять или сотня, всегда можно взять и завернуть в конфету. Проблема ровно одна — квалификация того человека, кто может майнтейнить эту мешанину кода.

Если подрядить на эту задачу эдакого Идеального Разработчика (любую задачу решает за 0 времени удовлетворяя 100% требований любой сложности), то ответ как бы очевиден. Фокус в том, что в обозримом будущем вероятность появления такого разработчика не так уж высока, что бы всерьез рассчитывать на положительный исход.

Здесь и помогает тот самый дизайн. Как я уже говорил, дизайн есть решение проблем, при чем не решение проблем по отдельности, а глобальное решение с учетом приоритетов(баланс, так сказать). Дизайн каждого модуля или фичи есть просто часть одного глобального дизайна.

Если отделить дизайн от паттернов, получается примерно следующее. Есть некоторая задача. Её необходимо решить используя некоторый формализм, пример — теория массового обслуживания. Далее, решение задачи необходимо перевести в код. Вот здесь, когда решение готово, можно выбрать оформление в виде десятка различных способов — например использовать ООП или взять за основу функциональную парадигму. Далее в каждой парадигме есть N способов выражения одного и того же решения в виде более конкретного кода. Например в ООП можно использовать наследование, а можно и отказаться от него. Если вдруг было решено использовать наследование, то можно использовать Template Method. А если решение требует поведения, то можно использовать State, а можно свести все к Dictionary и снова получить тот же результат. Если, вдруг, выбрана функциональная парадигма, то там есть аналоги тех же самых паттернов, только в профиль, ну, например, монады.

У адептов паттернов подход в корне отличный от этого — вместо решения самой проблемы они берут первые подходящие паттерны и начинают совать в код со страшной скоростью. Отсюда рождаются чудовища в духе "здесь у нас DI/IOC, тут Singletone, там моки и тд". Что интересно, цепочка рассуждений всегда одинаковая, независимо от решаемой задачи. Проблема в том, что нет никакой отправной точки, что бы внятно охарактеризовать решение. Ну разве кроме "у нас всё по паттернам, значит всё хорошо". Еще одна проблема, связаная с этим подходом не совсем очевидна. "Подумать" нужно время и сразу, "по-паттернам" времени не нужно и результат можно сходу демонстрировать кастомерам. С учетом засилья аутсорса и хронического лакейства большинства тамошних "командиров", создаётся очень странная ситуация на рынке, когда самые разные конторы хором ищут именно "специалистов по паттернам". Как по мне, так это поиски того самого Идеального Разработчика Когда кастомер готов платить, совершенно не важно, есть ли эффект и каковы затраты — четыре недели впятером или полтора года вдесятером.

class PersonController
{
  ...
  public Person Get(int id) 
  {
    _log.Info("someone has requested a person " + id);
    return _context.People.Single(p => p.Id == id);
  }
  ...
}

class PersonController {
  ...
  public Person get(int id) 
  {
    log.Info("someone has requested a person " + id);
    return personRepository.findOne(id);
  }
  ...
}

module.exports = function(Person, log) {
  return function(router) {
    router.get('/people/:id', function* () {
      var id = this.params.id;
      log.Info('someone has requested a person ' + id);
      this.result = yield Person.findOne(id);
    });
  };
};