(В оригинале - Engineer in the white spaces)

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

При этом одна маленькая стрелочка может означать что-то вроде «Синхронный запрос-ответ с использованием SOAP-XML поверх HTTP». И это слишком много информации для одной маленькой стрелочки. Часто даже не хватает места полностью это написать над этой стрелочкой, и мы сокращаем надпись до чего-нибудь вроде «XML over HTTP» для внутреннего использования или «SKU Lookup» для показа заказчику.

Эта стрелочка выглядит как непосредственный контакт между приложениями, однако это не так. Пространство между квадратиками, пустое на диаграмме, в реальности заполнено аппаратными и программными компонентами. Такими как:

• Сетевые карты
• Коммутаторы
• Файрволы
• Маршрутизаторы
• XML преобразователи
• FTP серверы
• Метро-сети
• MPLS шлюзы
• Океаны
• Рыболовные траулеры, случайно повреждающие сетями кабели

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

Однажды я видел стрелочку с надписью «Выполнение». Один сервер был внутри компании клиента, другой был в другой компании. Эта стрелочка, критичная для удовлетворенности заказчика, будучи распакованной в цепочку событий, стала напоминать головоломку, а не простой интерфейс. Сообщение отправлялось обработчику, который записывал его в файл, который загружался периодически запускаемым FTP процессом, и так далее. Всего шагов в этой последовательности оказалось более двенадцати!

Важно понимать все, что стоит за каждой стрелочкой. Вместо «SOAP-XML over HTTP» следовало написать «Потребуется один запрос для каждого HTTP запроса, плюс подтверждение для каждого HTTP ответа. Планируется около 100 запросов в секунду и доставка ответов за время не более чем 250 миллисекунд в течении 99.999% времени».

И даже это еще не все, что нужно знать об этой стрелочке. Без следующей информации нам тоже не обойтись:

• Что если запросы приходят слишком часто? Должны ли мы их отбрасывать без подтверждения, подтверждать отбрасывание или стараться обработать максимально возможное количество?
• Что должна предпринять другая сторона, если начнет получать ответы с задержкой более 250 миллисекунд? Пересоздать соединение? Подождать в течении заданного тайм-аута? Выдать сообщение о недоступности вызываемой стороны?
• Что если вызывающая сторона пошлет запрос версии 1.0 и получит ответ версии 1.1? А если получит HTML вместо XML? А если MP3 вместо XML?
• Что произойдет при отсутствии связи между сторонами?

И вот ответы на такие и им подобные вопросы и есть проектирование пустого пространства.

Автор оригинала - Michael Nygard