Лук против N-слоистой архитектуры

Одна вещь заранее: я прихожу из N-многоуровневого фона.

Теперь я потратил немало времени на то, чтобы обойти архитектуру Onion и связанные с ним концепции Domain Driven, такие как ресурсы чтения гексагональной архитектуры, такие как серия сообщений в блогах Джеффа Палермо, Взгляд Марка Зеемана с DI-перспективы, "Лучаризация вашей архитектуры" и "Чистая архитектура" .

Что все эти статьи имеют общее, так это то, что они заявляют следующие моменты:

  • Фокус сохраняется вокруг модели домена бизнес-случая
  • Ослабление связи между слоями путем подчеркивания принципа инверсии зависимостей
  • Повышенная независимость внешних инфраструктур, таких как структуры, постоянство данных, пользовательский интерфейс
  • Лучшая тестируемость/ремонтопригодность

Хорошо, что все звучит невероятно красиво, и эти диаграммы тоже выглядят хорошо. Но вопрос, который возникает для меня: не все ли это достигается простым добавлением фасадов в мою традиционную N-многоуровневую архитектуру?

  • Каждый слой просто знает абстракции слоя ниже
  • Конкретные реализации могут сохраняться внутри каждого слоя и, следовательно, находятся в том же месте, что и абстракции
  • Детали реализации могут быть легко заменены, поскольку они являются внутренними для уровня и не должны влиять на остальную часть приложения.

Пожалуйста, помогите мне понять истинные преимущества архитектуры, ориентированной на домен.

Спасибо заранее!

Ответы

Ответ 1

Добавление фасадов - действительно первый шаг в построении архитектуры лука из n-многоуровневой архитектуры. Итак, да, вы можете сразу получить много преимуществ.

Тестирование по-прежнему проблематично, так как вам нужно инвертировать элемент управления зависимостями. Контроль того, что имеет фасад, указывает на необходимость перехода к потребителю, а не к провайдеру. Это позволяет этому потребителю обменять вещи на тестирование или изменить реализации без того, чтобы провайдер знал об этом.

Ответ 2

Хотя это очень старый вопрос, но хотелось бы что-то добавить.

Onion Vs Layered

В этой статье четко объясняется, почему многоуровневое не предпочтительнее, но если вы правильно выполнили IOC, это не будет иметь никакого значения.

Ответ 3

Я разделяю то же мнение, что и ваше. Мы планируем начать новый проект, и один из моих коллег предложил архитектуру лука, но после небольшого описания этого документа я был немного смущен, потому что (для я!) тот факт, что каждый клиентский слой должен зависеть только от абстракции используемого слоя, является вопросом лучшей практики, который всегда должен иметь в виду любую архитектуру, которую мы планируем использовать, DI - это "Принцип", а не архитектура, поэтому Я не мог понять, как просто использование архитектуры N-Layered с "хорошими принципами OO" делает ее новой архитектурой?

Таким образом, мы закончим сотнями новых архитектур, просто объединив всех руководителей OO и шаблоны Go4 в архитектуре приложений Entreprise.

Ответ 4

Чтобы напрямую ответить на ваш вопрос "Не все ли это достигается путем простого добавления фасадов в мою традиционную N-многоуровневую архитектуру?". Ответ - да, и нет, в зависимости от вашего варианта использования.

Фокус архитектуры Onion на использовании инверсии зависимостей, как вы сказали, "создает более слабую связь". Тем не менее, это не только ради потери связи. Это может помочь подумать об этом как о "защите частей вашего кода, которые в наименьшей степени могут измениться, от частей, которые с большей вероятностью изменятся". Итак, для вашего случая, изменения "ниже" на фасаде потребуют изменений в вашем "доменном" коде? Может ли изменение, скажем, объекта базы данных, вносить изменения в объект, используемый в фасаде, а затем в ваш "доменный" код? Если ответ на эти типы вопросов "нет", то ваше предположение верно, нет значимой функциональной разницы для этого кода. Если кто-то должен был ответить "возможно", тогда они могут воспользоваться рефакторингом от фасадов до МОК.