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

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

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

Рис. 27.1.Организация системы-агрегатора услуг такси в виде комплекса служб

кандидатов для обслуживания клиента. Она собирает их во временной записи, прикрепленной к данному пользователю. Служба TaxiSelector получает критерии, обозначенные пользователем, касающиеся стоимости, времени, комфорта и т.д., и выбирает наиболее походящий вариант из списка кандидатов. Затем она передает выбранный вариант службе TaxiDispatcher, которая оформляет заказ.

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

В один прекрасный солнечный день сотрудники отдела маркетинга организовали встречу с разработчиками. На этой встрече они объявили о своем решении организовать услугу по доставке котят. Как предполагается, клиенты смогут заказать доставку котят себе домой или на работу.

Компания создаст несколько пунктов сбора котят по всему городу, и когда поступит заказ, ближайшее такси заберет котенка в одном из пунктов сбора и доставит по указанному адресу.

Один из поставщиков услуг согласился участвовать в этой программе. Другие, скорее всего, последуют его примеру, а третьи могут отклонить предложение.

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

А теперь взгляните на диаграмму служб и скажите, сколько из них придется изменить, чтобы реализовать описанную услугу? Все ! Совершенно понятно, что разработка и развертывание услуги доставки котят должны быть тщательно скоординированы.

Иными словами, все службы тесно связаны между собой и не могут разрабатываться, развертываться и сопровождаться независимо.

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

Как бы мы решили эту проблему в архитектуре, состоящей из компонентов? Неуклонное следование принципам проектирования SOLID вынудило бы нас создать набор классов, которые можно было бы полиморфно расширять под потребности новых возможностей.

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

Рис. 27.2.Использование объектно-ориентированного подхода для преодоления проблемы сквозных задач

Большая часть логики оригинальных служб сосредоточена в базовых классах объектной модели. Однако часть логики, связанная с поездками, выделена в компонент Rides. Реализация новой услуги по доставке котят помещена в отдельный компонент Kittens. Эти два компонента переопределяют абстрактные базовые классы из оригинальных компонентов с применением шаблонов, таких как « Шаблонный метод » или « Стратегия ».

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