Как придумывать SOA-сервисы
Архитекторов всегда ценили именно за это умение: придумать общую функцию, которая избавит разработчиков от нудной работы, сделать компонент, поведение которого задается файлом конфигурации, инкапсулировать сложное взаимодействие в простой программный интерфейс. Ведь именно это позволяет нам создавать повторно используемые (reusable) компоненты. И это крайне важно как для уменьшения сложности, так и для сокращения трудоемкости и времени доработки решений. Ранее я, по-моему, писал об этом только однажды, в заметке Работа ИТ архитектора – создание хороших абстракций, да ведь и тема не особо простая. Ну вот как сесть и начать придумывать эти самые хорошие абстракции?
Искушенный читатель скажет, что повторное использование достигается применением архитектурных паттернов. А я вот с этим не согласен. Когда у вас есть понимание, как сделать повторно используемый компонент, вы садитесь и пишете некоторый абстрактный класс, из которого другие смогут потом наследовать свои частные решения. А если в таком понимании чего-то не хватает, то вы пишите текст с описанием некоторой идеи и примерам. А другие программисты потом делают свой вариант реализации. Какое же это повторное использование?
Еще больше путаницы в этот вопрос вносит сервис-ориентированная архитектура. Во времена повышенного внимания к SOA обсуждалось повторное использование фрагментов бизнес-процессов, оформленных в виде сервисов. Если говорить языком трехуровневой архитектуры («данные – бизнес-логика – презентационный слой»), SOA призывала искать сервисы на уровне бизнес-логики. Но именно на уровне бизнес-логики представляются наименьшие возможности для обобщения и абстрагирования. Именно здесь нас преследует наибольшая вариативность и частые изменения. В любой крупной организации у заказчика всегда есть добрый десяток правил того, как он работает, и двадцать пять исключений из этих правил. Причем выявляются они в ходе эксплуатации системы и влекут за собой постоянные изменения. Сервис-ориентированную архитектуру можно рассматривать как некоторый вызов, призыв к бизнесу унифицировать процессы и операции, но не как решение. Какое уж здесь повторное использование, если нам постоянно приходится что-то дорабатывать?
Намного больше возможностей для создания reusable компонент лежит в уровне презентации. Это может быть дедовский способ генерации экранных форм на основании мета-данных или более утонченный способ, применяемый в лентах сообщений и мобильных приложениях. Подробнее об этом см. в заметке Mobile Human Task Application. Сейчас уже много об этом говорят. Посмотрите интересную статью Конец приложений, какими мы их знали или почитайте про Яндекс.Острова, выдающие экранные формы в результатах поиска. Очевидно, что здесь уже практически все придумано и остается только следить за тем, чтоб разработчики не хардкодили метаданные в пользовательский интерфейс.
Ну а что все же делать с бизнес-логикой? На мой взгляд, на техническом уровне эта задача вообще не решается. Если у вас есть требования, то вы будете реализовывать именно их. При этом вы не сможете выйти за пределы модели, которая была в голове написавшего эти требования аналитика. Возможно, заказчик потенциально и готов к обобщениям, но если разговаривавший с ним аналитик этого не прочувствовал, то возможность сделать что-то повторно используемое утрачена навсегда. Приведу простой пример. Многим аналитикам нравится диаграмма состояний (например, см. статью Григория Печёнкина Самые главные диаграммы). На мой взгляд, если аналитик сидит и придумывает состояния, то значит Главный архитектор уже лажанулся. Если вы хотите унифицировать процессы, то необходимые пользователю новые состояния должны не добавляться, а наследоваться из состояний эталонной модели процесса. Еще раз: аналитик не может придумывать новые состояния. Ему разрешено лишь сказать, что у некоторого состояния процесса/ресурса есть некоторый частный случай. Иначе вы никогда не сумеете собрать модели в единое целое, а интеграция между процессами (хореография) превратиться в нескончаемый процесс отображения состояний и переходов, реализованных в одной системе, в состояния и переходы, придуманные в другой системе. Это как реляционные базы данных и объектно-ориентированный подход. ООП появился как ответ на неуправляемый рост количества табличек в базах данных. Как только нам требовалось добавить к некоторому объекту новое свойство или отношение, мы создавали в БД новую сущность (или уродовали старую, добавляя новое свойство сразу ко всем объектам). С появлением классов, благодаря механизму наследования, мы можем действовать более тонко. А механизм полиморфизма позволяет расширять не только структуру объекта, но и его поведение. Но это все происходит на технологическом уровне. А на уровне рабочих процессов и бизнес-логики, если об этих механизмах кому-нибудь и известно, то знание это чисто теоретическое.
Представьте себе процесс, нарисованный в красивой BPMN нотации. Как вы станете его расширять или конкретизировать? (Под «конкретизировать» я понимаю создание частного случая процесса. Впрочем, под «расширять» я понимаю примерно это же.) Правильно! Добавляя новые активности и ветвления в уже существующий процесс. Это не повторное использование, это переработка. И такое действие несет все присущие переработке компонента проблемы. Надо разобраться, что следует исправить, найти, где это сделать, протестировать, ошибиться с версиями при развертывании и т.д. Хорошо еще, если вы знакомы с техникой Алистера Коберна и думаете о процессе как о наборе расширений основного сценария. А если в вашем представлении процесс — это граф, то уже никакой process mining не поможет.
Возможно, я сгущаю краски и у кого-то из читателей есть свой рецепт изобретения SOA-сервисов. Может, я чего-то не понял или какую-нибудь важную книжку не прочитал. Если это так, то убедительно прошу поделиться своими соображениями.
© Издание 12NEWS (ИП Маринин А.Л.), 2014
