(В оригинале - Don't Control, but Observe)

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

Таким образом, затратить усилия на построение гибкой и эволюционирующей системы – это хорошая идея. Но это также означает и то, что наша система будет постоянно меняться со временем. Система сегодня уже не будет такой, какая она была вчера. К сожалению, это делает документирование системы очень нетривиальной задачей. Хорошо известен факт, что документация устаревает в тот момент, когда отправляется на печать. Но для постоянно меняющейся системы все еще гораздо хуже. К тому же если система гибкая, то это также означает и то, что она достаточно сложна, и как следствие, сделать пресловутую “big picture” тоже будет сложно. Например, если все компоненты системы связываются друг с другом при помощи логических, конфигурируемых каналов, то лучше посмотреть на конфигурацию каналов, чтобы понять, что происходит. Отправка сообщения без понимания системы вряд ли приведет к ошибке компилятора, но наверняка расстроит пользователя, чьи действия были инкапсулированы в этом сообщении.

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

Во многих случаях получившуюся модель легко визуализировать. Однако сопротивляйтесь искушению нарисовать плакат 3 на 5 метров, весь заполненный квадратиками и линиями и содержащий каждый класс в вашей системе. Получившаяся картина может занять призовое место на выставке современного искусства, но не будет являться пригодной к использованию моделью. Вместо этого, используйте вид с высоты 300 метров, описанный Эриком Дорненбургом – уровень абстракции, который может реально показать полезную информацию. В результате вы сможете также убедиться, что модель соответствует определенным правилам, например, что в ней отсутствуют циклические зависимости или что никто не посылает сообщения в канал, который никем не прослушивается.

Потеря контроля – ужасная вещь, даже если речь идет об архитектуре ПО. Но если это дополнить наблюдением, извлечением модели и проверкой на корректность, то в результате получится способ проектирования 21-го века.

Автор оригинала - Gregor Hohpe.