Роберт Мартин - Чистая архитектура. Искусство разработки программного обеспечения

game.setQuiver(5);

}

// здесь следует еще много кода...

}

Компонент Main — самый грязный низкоуровневый модуль, находящийся во внешнем круге чистой архитектуры. Он загружает все, что потребуется системе более высокого уровня, а затем передает ей управление.

Представьте, что Main является плагином для приложения — плагином, который настраивает начальное окружение, загружает все внешние ресурсы и затем передает управление политике верхнего уровня. Так как это плагин, может иметься множество компонентов Main, по одному для каждой конфигурации приложения.

Например, у нас может иметься плагин Main для разработки , еще один для тестирования и третий для эксплуатации . Можно также создать по плагину Main для каждой страны, или каждой юрисдикции, или каждого клиента.

Когда вы начинаете думать о компоненте Main как о плагине, находящемся за архитектурной границей, проблемы настройки решаются намного проще.

Сервис-ориентированные «архитектуры» и микросервисные «архитектуры» приобрели особую популярность в последнее время. Эта популярность обусловлена, в том числе, следующими причинами:

• Службы выглядят полностью независимыми друг от друга. Но, как мы увидим далее, это верно лишь отчасти.

• Службы, похоже, можно разрабатывать и развертывать независимо. И снова, как мы увидим далее, это верно лишь отчасти.

Прежде всего уточним, что утверждение, будто использование служб по своей природе является архитектурой, в принципе неверно. Архитектура системы определяется границами, отделяющими высокоуровневые политики от низкоуровневых деталей, и следованием правилу зависимостей. Службы, просто делящие приложение на функциональные элементы, по сути, являются лишь функциями, вызовы которых обходятся довольно дорого и не обязательно имеют важное архитектурное значение.

То есть не все службы должны быть архитектурно значимыми. Часто бывает выгодно создавать службы, распределяющие функциональные возможности по разным процессам и платформам, независимо от того, подчиняются ли они правилу зависимостей. Службы сами по себе не определяют архитектуру.

Наглядной аналогией является организация функций. Архитектура монолитной или компонентной системы определяется некоторыми вызовами функций, пересекающими архитектурные границы и следующими правилу зависимостей. Однако многие другие функции в системе просто отделяют одно поведение от другого и не являются архитектурно значимыми.

То же верно в отношении служб. Службы, в конечном счете, — это всего лишь вызовы функций через границы процессов и/или платформ. Некоторые из этих служб действительно являются архитектурно значимыми, а другие — нет. Основной интерес для нас в этой главе представляют первые.

Знак вопроса в заголовке указывает, что в этом разделе мы поставим под сомнение популярное мнение о сервис-ориентированной архитектуре. Давайте рассмотрим предполагаемые преимущества по одному.

Одно из самых больших предполагаемых преимуществ деления системы на службы заключается в полной независимости их друг от друга. В конце концов, каждая служба выполняется в отдельном процессе или даже на другой машине; поэтому службы не имеют доступа к переменным друг друга. Более того, для каждой службы должен быть четко определен ее интерфейс.

Все это верно до определенной степени, но не до конца. Да, службы независимы на уровне отдельных переменных. Но они все еще могут быть связаны вместе общими ресурсами на одной машине или в сети. Более того, они тесно связаны общими данными.

Например, чтобы добавить новое поле в запись, которая передается между службами, придется изменить все службы, использующие это новое поле. Службы должны также согласовать интерпретацию данных в этом поле. То есть службы тесно связаны с записью и, соответственно, косвенно связаны друг с другом.

Утверждение о необходимости четко определять интерфейс тоже верно, но оно в той же мере относится к функциям. Интерфейсы служб не являются более формальными, строгими и четкими, чем интерфейсы функций. Как видите, это преимущество довольно иллюзорно.

Другое предполагаемое преимущество — возможность передачи служб во владение отдельным командам. Каждая такая команда может отвечать за разработку, сопровождение и эксплуатацию службы, как это предполагает стратегия интеграции разработки и эксплуатации (DevOps). Такая независимость разработки и развертывания, как предполагается, является масштабируемой. Считается, что крупные корпоративные системы могут состоять из десятков, сотен и даже тысяч служб, разрабатываемых и развертываемых независимо. Разработку, сопровождение и эксплуатацию системы можно разделить между аналогичным количеством независимых команд.

Это утверждение верно, но лишь отчасти. Во-первых, как показывает история, крупные корпоративные системы могут состоять из монолитных и компонентных систем, а также из систем, состоящих из служб. То есть службы не единственный способ построения масштабируемых систем.

Во-вторых, как было показано в разделе «Заблуждение о независимости», службы не всегда могут разрабатываться, развертываться и эксплуатироваться независимо. Их разработку приходится координировать в той же мере, в какой они связаны данными или поведением.

Чтобы рассмотреть эти два заблуждения на примере, вернемся снова к нашей системе агрегатора такси. Как вы помните, эта система знает о нескольких компаниях, предоставляющих услуги такси в данном городе, и позволяет клиентам заказывать поездки. Представим, что клиенты выбирают такси по ряду критериев, таких как время ожидания, стоимость, комфорт и опытность водителя.

Мы решили для большей масштабируемости реализовать ее в виде множества маленьких микрослужб. Мы разделили большой коллектив разработчиков на множество маленьких команд и каждой поручили разработку, сопровождение и эксплуатацию соответствующего [53] Примерно по числу программистов в команде. количества микрослужб.

Схема на рис. 27.1 демонстрирует, как наши предполагаемые архитекторы распределили ответственность приложения между микрослужбами. Служба TaxiUI взаимодействует непосредственно с клиентом, заказывающим такси с помощью своего мобильного устройства. Служба TaxiFinder исследует параметры разных поставщиков услуг TaxiSupplier и выбирает возможных