Почему не все сервисы одинаково полезны

inversionВ программировании известен такой архитектурный паттерн как Inversion Of Control. Суть его в следующем. Традиционно, повторно используемый код оформлялся в виде функций, которые впоследствии вызывались из основной программы. Функции оформлялись в виде статических библиотек, динамических библиотек или вообще в виде сервисов. Приходил программист. Брал функциональные требования, реализовывал бизнес-логику в виде отдельной программы, которая при необходимости вызывала эти самые функции. Inversion Of Control переставляет все с ног на голову. Мы пишем готовую программу, внутри которой реализуем повторно используемый функционал. При этом мы предусматриваемые некоторые точки расширения, в которых вызываются функции, реализующие бизнес-логику. В качестве примера можно привести функцию обработки сообщений главного окна приложения Windows именуемую MainWndProc(). В объектно-ориентированном программировании приложение часто наследуется от некоторого базового класса. Идея микроядра, управляемая событиями архитектура, HATEOAS  это тоже об инверсии управления. Но чаще всего IoC используется в веб-программировании, в частности в  системах управления контентом. Реализация идеи инверсии управления воплощается в инструментарии, который называют software framework. Англоязычная статья википедии лаконично, но достаточно хорошо описывает фреймворк, как программное обеспечение обладающее следующими свойствами:

  • inversion of control – как уже было сказано выше, в отличии от традиционных программ или библиотек поток управления задает framework
  • default behavior – framework обладает некоторым полезным поведением по умолчанию
  • extensibility – основное свойство framework это способность к расширению; это могут быть создаваемые пользователем конфигурации или разрабатываемые  программистом модули, реализующие требуемую функциональность
  • non-modifiable framework code – программный код фреймворка не должен меняться; заказчик может расширить его, создавая дополнительные модули, но не может модифировать.

Framework обладает как определенными преимуществами, так и некоторыми недостатками. К недостаткам обычно относят избыточность, большой объем неиспользуемого кода. Ну, а очевидное преимущество заключается в быстроте разработки решений. Но есть и неочевидные преимущества. Во-первых, это сохранение концептуальной целостности. Пока вы смотрите на свое решение как на набор библиотек, разрабатываемых различными командами, сохранить концептуальную целостность крайне сложно. Как только вы переходите к архитектуре framework (или, если угодно, микроядра), все встает на свои места. Ядро пишет небольшая группа опытных разработчиков. Прикладные программисты разрабатывают расширения. Следующее неочевидное преимущество заключается в разделении труда. Расширения могут быть разными. В системах управления контентом принято разделять разработку дизайна (тем) и расширений. В сервисной шине кто-то пишет адаптеры протоколов, а кто-то бизнес-логику и т.д. Может это и не серебряная пуля, которую начал искать еще Брукс в мифическом человеко-месяце, но уже хоть что-то для борьбы с монстром complexity. Ну и в третьих это вполне рабочий способ ограничения глубины изменений.

Теперь о корпоративной архитектуре. Сервис-ориентированная архитектура(SOA) поставила вопрос единого взгляда на корпоративный ИТ-ландшафт, но предложила не очень вразумительный ответ. Дополнившая её управляемая событиями архитектура (event driven architecture), по сути своей, предложила SOA в формате Inversion Of Control. Т.е. мы не складываем нашу информационную систему предприятия из многочисленных сервисов, а смотрим на неё как не единый framework, содержащий уже и основные данные и бизнес-процессы и группы пользователей. А новые информационные системы должные не свободно произрастать как сорняки в заброшенном огороде, а расширять существующую корпоративную ИС. Очевидная задача корпоративного архитектора управлять этим процессом, подключать расширения, сохраняя неизменность работающего framework-а

IoC

Почему не все сервисы одинаково полезны: 5 комментариев

  1. У Inversion Of Control и сопутствующих расширений есть еще один существенный недостаток. Когда Система построенная на расширениях живет достаточно долго, то накапливается такое количество версий этих самых расширений, что в какой-то момент управлять совместимостью между расширениями становиться сложно.

    1. Именно поэтому негласным правилом для некоторых разработчиков является поддержка -1 версии. То есть если сейчас версия 4, то разработчик поддерживает еще и 3, а 2 и 1 уже за бортом как слишком устаревшие морально. Соответственно и совместимость строится похожим образом. Хотя это все условно.

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *