Паттерн «VIP сервис»

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

Паттерн не привязан к языкам программирования.

Картинка для привлечения внимания:

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

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

Что в этой ситуации делают проектировщики\архитекторы? Самое правильное решение это отказ от новой функциональности всеми доступными методами, потому что самый хороший код это код который не написан. Такой код легко поддерживается и содержит минимальное колличество багов. Способы воздествия могут быть различными, от давления авторитетом до использования различных уловок, например, позволить обыграть себя в Quake ©.

Второе решение, если позволяет ситуация, в рабочем порядке пересмотр архитектуры и если необходимо, перепроектирование.

Если же времени для оценки и перепроектирования нет а решение требуется «вчера», то приходится брать «технический долг». Самый тяжелый случай — фнкциональность необходимо пробросить через несколько слоев.

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

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

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

Плюсы:

• Функциональность доступна сразу
• Выигрыш времени на проработку правильного решения
• Технические долги не расползаются по системе
• Быстрый доступ ко всем долгам системы (для оценки проблем архитектуры)
• Возможны решения целого класса проблем, так как решения конкретных проблем откладываются

Минусы:

• Паттерн не везде применим

Всем спасибо за понимание!