[r]evolutionary architecture

Если вы читали книгу Сэма Ньюмена «Создание микросервисов» (Building Microservices. Designing Fine-Grained Systems By Sam Newman), то могли столкнуться с ощущением когда за словами теряется смысл. В книжке приводятся совершенно верные рассуждения о синхронных и асинхронных взаимодействиях, архитектуре и интеграции, разнице между оркестровкой и хореографией, непрерывном развертывании и мониторинге и даже страшной аббревиатуре HATEOAS. Но за всеми этими вполне разумными суждениями сложно разглядеть ответ на вопрос «Зачем?» В какой-то мере ответ на этот вопрос дается другими экспертами ThoughtWorks в концепции Evolutionary Architecture. Статья тоже довольно абстрактна, но прикладываемые к ней видео семинаров и выступлений на конференциях позволяют догадаться, о чем идет речь. Выскажу свою версию надеясь, что она не очень далека от оригинального суждения.

Проектирование приложений в сервис-ориентированном подходе выглядело следующим образом. Приходил [умный] архитектор и декомпозировал задачу на модули. Делал он это не просто так, а с вполне благородными целями: распараллелить разработку между несколькими командами, локализовать влияние будущих изменений, сократить дублирование функционала и добиться потенциального повторного использования. В ходе такой декомпозиции вырисовывался ряд модулей, которые целесообразно оформить в виде сервисов. Т.е. приложение разбивалось на некоторый центральный компонент, реализующий бизнес-логику и набор вспомогательных сервисов, которые эта логика вызывает. Сервис предполагается создавать более-менее стабильными, так чтоб их приходилось дорабатывать не особо часто и потенциально можно было бы использовать в других приложениях. В общем такой вот Big Design Up Front (BDUF). В основе создания повторно используемых сервисов лежит абстрагирование (см. Работа ИТ архитектора – создание хороших абстракций и Как придумывать SOA-сервисы).

Идея эволюционирующей архитектуры прямо противоположная. В какой-то мере она напоминает паттерн Inversion of Control (см. Почему не все сервисы одинаково полезны) Сначала мы пишем некоторое легковесное ядро, в котором реализуем некоторые довольно абстрактные идеи. Это ядро является стабильным, не меняется в большинстве релизов и вызывает микросервисы. Конкретная бизнес-логика реализуется внутри оформленного в виде плагина или расширения микросервиса. При её изменении, что происходит довольно часто, мы делаем новый микросервис и прикручиваем его вместо или вместе с существующим. Примерами подобного рода задач являются обработчики команд, процессы подготовки данных по потоку сообщений, в общем сплошной CQRS. Вслед за первым уровнем микросервисов вырастает второй, затем третий, в общем формируется своеобразная паутина. В ходе эволюции приложения часть микросервисов умирает, другие заменяются, но вся система в целом постепенно наращивает функционал.

Чем-то это похоже на инкрементное итеративное написание Use cases à la Alistair Cockburn. С начала мы реализуем типичный ход событий. Потом добавляем к нему обработчики исключений и расширения. По мере того, как наш юзкейс развивается, он начинает «цеплять» новые источники данных и программные интерфейсы, за которыми стоят другие сценарии, а они в свою очередь завязаны на прочие объекты… и так без конца.

[r]evolutionary architecture: 5 комментариев

  1. Это не «эволюционная архитектура», а «эволюционная реализация». Другими словами, начинаем с «Hello, world» и строим любое приложение.

    Архитектура обязательна всегда, а правильная архитектура – еще лучше. С помощью микросервисов, можно перейти от разработки архитектуры для конкретного приложения, к использованию паттернов архитектуры приложений. Примеры таких паттернов – data-entry application, process-centric application, info-portal, event-driven, etc. Для каждого паттерна надо начинать с определенных архитектурных работ. Например, для process-centric application для быстро прототипнуть процессы и начать рутинную работу à la agile.

    1. Да. Совершенно верно. Спасибо! Evolutionary architecture это как раз о том, как поддержать адаптивный инкрементный процесс реализации, с возможностью постановки экспериментов, split тестирования, безопасного развертывания и пр. В части обработки команда это скорее event-driven подход, в части предоставления данных – resource/web oriented architecture.

      Если же говорить о process-centric application то здесь все не очень понятно, потому как form-driven workflow – это ориентированное на процесс приложение и guided navigation тоже, да и case management… Но все это довольно разные виды приложений. Монолитный BPMS c архитектурной точки зрения сильно отличается от BPEL Engine + Human Task, например.

      1. “Если же говорить о process-centric application то здесь все не очень понятно” – есть тендеция к преодолению искуственного разделения на form-driven workflow, guided navigation, case management и проч. А BPEL Engine + Human Task уже не вспоминается.

        Также event-driven, resource/web oriented architecture и process-centric могут быть нужны для любого приложения, но с разными “весовыми коэффицентами”. Главное определить доминирующие в конкретном случае артефакты и начать с них.

        Согласен, что монолитный BPMS это устаревшая архитектура и надеюсь что будет как с Кафагеном.

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

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