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

Question

Одна вещь заранее: я прибываю из N-слоистого фона.

я теперь потратил довольно немного времени получать мою голову вокруг Луковый архитектуры и связанных с доменными Driven концепций, таких как шестиугольная Архитектура чтения ресурсов, как Jeff Palermo's series of blog posts, Mark Seemann's contribution from a DI-perspective, "Onion-izing your achitecture" и "The clean architecture".

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

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

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

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

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

Заранее благодарен!

Answer 1

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

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

Answer 2

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

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

Answer 3

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

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

Answer 4

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

Onion Vs Layered

Эта статья объясняет, почему ясно слоистые не является предпочтительным, но если вы правильно реализованы МОК, он не собирается делать никакой разницы.