В предыдущей статье мы рассмотрели маленький паттерн для упрощения кода пользователей сервисов, в этой статье мы рассмотрим особый вид сервиса. Данный паттерн применяется в архитектурах имеющих слои, если рассматриваемая архитектура не имеет слоев, то паттерн может не иметь нужного эффекта либо быть вообще вредным.
Паттерн не привязан к языкам программирования.
Картинка для привлечения внимания:
Представим себе ситуацию, мы имеем крупный проект, который уже сформировался и прошел стадию бурного перепроектирования. Проект имеет слои, все реализовано технически грамотно (да, такое бывает) и архитектура позволяет реализовать подмножество текущего функционала. Разработка идет по планам без перегибов и кранчей.
Но в какой то момент возникает идея или требование в одной из светлых голов дизайнеровинвесторовкреативных директоров или артистов (нужное подчеркнуть). Эта идея не ложится в текущую архитектуру. Это не обязательно может быть идея как новая функциональность, это может быть, например, поддержка кастомного функционаларежима одного из поставщиков промежуточного софта которое дает какое либо преимущество, например техническое.
Что в этой ситуации делают проектировщикиархитекторы? Самое правильное решение это отказ от новой функциональности всеми доступными методами, потому что самый хороший код это код который не написан. Такой код легко поддерживается и содержит минимальное количество багов. Способы воздействия могут быть различными, от давления авторитетом до использования различных уловок, например, позволить обыграть себя в Quake ©.
Второе решение, если позволяет ситуация, в рабочем порядке пересмотр архитектуры и если необходимо, перепроектирование.
Если же времени для оценки и перепроектирования нет а решение требуется «вчера», то приходится брать «технический долг». Самый тяжелый случай — функциональность необходимо пробросить через несколько слоев.
Негативные последствия таких решений известны. Верхние слои становятся зависящими от деталей нижних слоев, появляются сервисы посредники которые нужны только для того чтобы пробрасывать функциональность и др.
Для решения проблемы замусоривания архитектуры пробросами и их негативного влияния на архитектуру в целом и служит данный паттерн. Суть паттерна заключается в том, чтобы инкапсулировать все долги в единый сервис, либо цепочку сервисов. Такой сервис будет является фасадом ко всем техническим долгам системы.
Важно понимать что данный паттерн не является частью архитектуры и нужен лишь для инкапсуляции временных решений, позволяя выиграть время на оценку и перепроектирование не разрушая текущую архитектуру.
Плюсы:
- Функциональность доступна сразу
- Выигрыш времени на проработку правильного решения
- Технические долги не расползаются по системе
- Быстрый доступ ко всем долгам системы (для оценки проблем архитектуры)
- Возможны решения целого класса проблем, так как решения конкретных проблем откладываются
- Прямой выигрыш если в функциональности отпадет надобность
Минусы:
- Паттерн не везде применим
Всем спасибо за понимание!
Автор: mynameco
