Ясно, что в этой схеме после реализации Kittens придется изменить TaxiUI. Но все остальное останется в прежнем виде. В систему добавится лишь новый файл jar, Gem или DLL, который будет динамически загружаться во время выполнения системы.
То есть компонент Kittens существует отдельно от других и может разрабатываться и развертываться независимо.
Службы на основе компонентов
Возникает резонный вопрос: можно ли реализовать нечто подобное для служб? И ответ, конечно, да! Службы не обязательно должны быть маленькими монолитами. Службы также могут проектироваться в соответствии с принципами SOLID и данной структурой компонентов, чтобы иметь возможность добавлять в них новые компоненты, не изменяя существующие.
Представьте службу на Java как набор абстрактных классов в одном или нескольких jar-файлах. Каждую новую возможность или расширение существующей возможности можно реализовать как отдельный jar-файл, содержащий классы, наследующие абстрактные классы из уже имеющихся jar-файлов. Для развертывания новой возможности в этом случае больше не потребуется повторно развертывать службы, достаточно лишь добавить новые jar-файлы в пути загрузки этих служб. Иными словами, добавление новой возможности выполняется в соответствии с принципом открытости/закрытости (Open-Closed Principle; OCP).
Схема на рис. 27.3 демонстрирует такую организацию служб. На ней представлены все те же службы, только на этот раз каждая состоит из компонентов, что позволяет добавлять новые возможности, реализованные в виде новых производных классов. Эти производные классы находятся в собственных компонентах.
Рис. 27.3. Каждая служба состоит из компонентов, что позволяет добавлять новые возможности, реализованные в виде новых производных классов
Сквозные задачи
Теперь мы знаем, что архитектурные границы не всегда совпадают с границами между службами. Часто эти границы проходят через службы, деля их на компоненты.
Для преодоления проблем, связанных со сквозными задачами, с которыми сталкиваются все достаточно крупные системы, службы должны иметь компонентные архитектуры, следующие правилу зависимостей, как показано на рис. 27.4. Эти службы не определяют архитектурные границы в системе; границы определяются компонентами в службах.
Рис. 27.4. Службы должны иметь компонентные архитектуры, следующие правилу зависимостей
Заключение
Несмотря на все преимущества масштабируемости и удобства разработки системы, службы не являются архитектурно значимыми элементами. Архитектура системы определяется границами, проводимыми внутри этой системы, и зависимостями, пересекающими эти границы. Архитектура не определяется физическими механизмами, посредством которых элементы взаимодействуют и выполняются.
Служба может быть единственным компонентом, полностью окруженным архитектурной границей. Но точно так же служба может состоять из нескольких компонентов, разделенных архитектурными границами. В редких
[54] случаях клиенты и службы могут быть настолько связаны, что не могут иметь архитектурной значимости.
Глава 28. Границы тестов
Да, все правильно: тесты являются частью системы и занимают свое место в архитектуре, как любые другие части системы. В одних случаях это вполне нормальное явление. В других оно может быть уникальным.
Тесты как компоненты системы
С тестами связано много неясностей. Являются ли они частью системы? Должны ли они отделяться от системы? Какие виды тестов бывают? Являются ли модульные и интеграционные тесты разными тестами? Какое место во всем этом занимают приемочные тесты, функциональные тесты, тесты для фреймворка Cucumber, тесты TDD, тесты BDD, тесты для компонентов и т.д.?
Обсуждение данной конкретной темы не является целью этой книги, и, к счастью, этого не требуется. С архитектурной точки зрения все тесты одинаковы. Будь то маленькие тесты TDD, или большие тесты FitNesse, Cucumber, SpecFlow, или JBehave — все они архитектурно эквивалентны.
Тесты по самой своей природе следуют правилу зависимостей; они очень детальны и конкретны; и они всегда зависят от тестируемого кода. Фактически тесты можно считать самым внешним кругом архитектуры. Ничто в системе не зависит от тестов, но тесты всегда зависят от внутренних компонентов системы.
Тесты также можно развертывать независимо. Фактически в большинстве случаев они развертываются в тестовых системах, но не развертываются в производственных системах. То есть даже в системах, где независимое развертывание не требуется, тесты все равно развертываются независимо.
Тесты являются наиболее изолированными компонентами системы. Они не нужны системе для нормального функционирования. Пользователи не зависят от них. Их роль — поддержать разработку, но не работу. И все же они являются не менее важным системным компонентом, чем любые другие. Фактически они представляют модель, которой должны следовать все остальные компоненты.
Проектирование для простоты тестирования
Крайняя степень изоляции тестов в сочетании с тем фактом, что они обычно не развертываются, часто заставляет разработчиков думать, что тесты выходят за рамки дизайна системы. Это абсолютно неверная точка зрения. Тесты, недостаточно хорошо интегрированные в дизайн системы, обычно оказываются хрупкими и делают систему жесткой и неудобной для изменения.
Проблема, конечно, заключается в тесной зависимости. Тесты, тесно связанные с системой, должны изменяться вместе с системой. Даже самые безобидные изменения в системном компоненте могут нарушить нормальную работу многих связанных тестов или потребовать их изменения.
Эта ситуация может приобретать особую остроту. Изменения в общих системных компонентах могут нарушить работу сотен и даже тысяч тестов. Эта ситуация известна как «проблема хрупких тестов».
Нетрудно понять, как это может произойти. Представьте, например, набор тестов, использующих графический интерфейс для проверки бизнес-правил. Такие тесты могут начинать работу на странице авторизации и затем последовательно переходить от страницы к странице, проверяя определенные бизнес-правила. Любое изменение в странице авторизации или в структуре навигации может нарушить работу большого количества тестов.
