Мобильность инфраструктуры через архитектуру лука - практические последствия

Question

Одним из ключевых преимуществ, предоставляемых архитектурой Onion, является возможность поменять элементы инфраструктуры, такие как «Доступ к данным, ввод-вывод и веб-службы» (http://jeffreypalermo.com/blog/the-onion-architecture-part-3/).

Джефф говорит на своем посту с 2008 года, что «индустрия модифицировала методы доступа к данным не реже одного раза в три года».

Есть ли у кого-нибудь пример достаточно крупного проекта, в котором использовалась архитектура Луны и впоследствии была заменена ключевые элементы инфраструктуры?

Я заинтересован, чтобы понять:

• Как часто этот сценарий, в целом?

Мой инстинкт говорит мне, что, хотя «методы доступа к данным» могут быть изменены каждые три года, изменения в реальной инфраструктуре для запуска решений, которые позволили бы реализовать эту выгоду, могут быть намного реже?

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

Мне интересно узнать, были ли неожиданные изменения требуемыми, помимо замены компонента инфраструктуры и реализации того же интерфейса. Например, чтобы новая инфраструктура требовала передачи новых аргументов ранее определенным методам, например. SaveOrder (int ID) -> SaveOrder (int ID, bool AllowSiblings, bool SiblingCreated) при переходе от модели реляционной к NoSQL DB.

• ли осуществление этой архитектуры + переделок перейти на новую инфраструктуру значительно снизить общее усилие, необходимое, если по сравнению с традиционным, в сочетании подхода?

• Помогают ли разработчики найти связанный код с жесткой привязкой легче писать и отлаживать, чем свободно связанный, косвенно ссылочный код, но возможный выигрыш для изменений инфраструктуры делает это того стоит?

Answer 1

Ну, ИМХО, основная цель подобной архитектуры стиля (Hexagoanl, порты & адаптеры, лук ...) является то, что она позволяет вам сосредоточиться на своем домене, как вы будете приносить пользу вместо того, чтобы сосредоточиться в первую очередь на пользовательском интерфейсе , фреймворки или проблемы с хранением. Это позволяет отложить принятие таких решений.

Как Джеффри говорит, способность обмениваться элементами «инфраструктуры» является хорошим побочным эффектом такого стиля архитектуры. Даже если вы не будете переключаться с одной РСУБД на другую каждые 6 месяцев, это вполне обнадеживает, зная, что можно было бы сделать это без боли.

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

Прочитайте this nice Uncle Bob article о чистой архитектуре, где он объясняет, почему способность откладывать критическую инфраструктурную ситуацию действительно крута!

--- EDIT ---

Не могли бы вы привести пример того, где вы выгружена услугу третьего лица?

У нас есть множество примеров, когда мы перешли от одного провайдера к другому (от поставщиков платежей до поставщиков живых каналов или любого другого провайдера). Бизнес остается прежним, поведение домена по-прежнему остается прежним. Изменение поставщика не должно оказывать какого-либо влияния на ваш бизнес. Вам не нужно менять способ работы вашего бизнеса, где это действительно так, просто потому, что вы меняетесь от одного провайдера к другому, это не имеет никакого смысла. Изоляция поведения вашего домена на отдельном базовом уровне без каких-либо зависимостей от каких-либо сторонних библиотек, фреймворков или поставщиков услуг, безусловно, поможет вам справиться с изменениями.

У меня такое чувство, что вы пытаетесь убедить себя, пойти ли с луком. Возможно, вы ошибаетесь, думая только о переходе на новую инфраструктуру (db, сторонние вещи ...). Вместо этого сосредоточьтесь на своем домене. Спросите себя, достаточно ли для вашего домена достаточно сложного архитектурного стиля. Не используйте базуку, чтобы убить муху. Как Simon Brown говорит: «Принципы хороши, но убедитесь, что они реалистичны и не оказывают отрицательного воздействия.«!

Если ваше приложение довольно малое, без сложного бизнес-домена, пойдите для классической архитектуры n-уровня, это нормально; не изменяйте вещи только ради этого или просто из-за какого-либо модного слова. Но также имейте в виду, что изолированный базовый бизнес-уровень без зависимостей, как в архитектуре Onion, может быть очень простым для модульного тестирования!

Теперь для дополнительных вопросов:

ли реализация этой архитектуры + переделки перейти на новую инфраструктуру значительно снизить общее усилие, необходимое, если по сравнению с традиционным, в сочетании подхода?

Всё зависит! :-) В приложениях с жесткой связью, как только будет перенесен новый элемент инфраструктуры, нет сомнений в том, что вам обязательно придется модифицировать код на всех уровнях (включая бизнес-уровень). Но если это приложение малое, довольно простое, хорошо организованное с охватом тестового кода спуска, это не должно быть большой проблемой. Теперь, если он довольно большой, с более сложным бизнес-доменом, может быть хорошей идеей изолировать этот слой на совершенно отдельном уровне без каких-либо зависимостей, гарантируя, что изменения в инфраструктуре не вызовут какой-либо деловой регрессии.

Помогают ли разработчики найти связанный код с жесткой привязкой легче писать и отлаживать, чем свободно связанный, косвенно ссылочный код, но возможный выигрыш для изменений инфраструктуры делает это того стоит?

Ну, спросите своих товарищей по команде! Используются ли они для работы с МОК? Помните, что дизайн и выбор архитектуры должны быть решением команды.Это должно быть что-то общее для всей команды.