Fitness Functions и эволюционная архитектура

Что такое fitness function

Термин пришёл из книги Нила Форда, Ребекки Парсонс и Патрика Куа «Building Evolutionary Architectures» (O’Reilly, 2017). Они позаимствовали его из эволюционных вычислений, где fitness function оценивает, насколько хорошо кандидат-решение удовлетворяет требованиям задачи.

В архитектуре fitness function — любой механизм, обеспечивающий объективную, автоматизированную оценку того, выполняется ли архитектурная характеристика по-прежнему. Это не документация. Это не чеклист для code review. Это запускается в CI и выдаёт pass или fail.

Архитектурные характеристики — иногда называемые «-ilities» — это нефункциональные свойства, которые архитектура должна сохранять:

• Модульность: ни один модуль не импортирует из внутренностей другого
• Задержка: p99 времени ответа billing API не превышает 200 мс
• Отсутствие циклических зависимостей: нет циклов между модулями на уровне пакетов
• Безопасность: чувствительные данные не попадают в логи
• Масштабируемость: система может обработать 10 000 генераций инвойсов в минуту

Fitness function превращает эти характеристики из пожеланий в гейты сборки.

Atomic vs holistic fitness functions

Форд, Парсонс и Куа выделяют два измерения fitness functions: область охвата и частота.

Atomic fitness functions тестируют одну архитектурную характеристику изолированно:

• «Нет циклических зависимостей между модулями» — одно правило ArchUnit
• «Нет прямых импортов из внутреннего пакета другого модуля» — правило ts-arch или ESLint
• «Все методы публичного API возвращают ответ в пределах 50 мс в unit-тестах» — assertion производительности в тест-сьюте

Holistic fitness functions тестируют комбинацию характеристик, проявляющихся только совместно:

• «При 10 000 RPM система поддерживает p99 < 200 мс И частоту ошибок < 0,1% И отсутствие OOM» — нагрузочный тест в CI
• «Задеплоенная система проходит сканирование безопасности И аудит зависимостей И отсутствие кросс-граничного доступа в продакшн-трейсах» — составной гейт

Большинство команд начинают с atomic fitness functions, потому что они дёшевы в написании и быстры в выполнении. Holistic functions дороже, но выявляют эмерджентные режимы отказа, которые атомарные тесты пропускают.

Triggered vs continuous fitness functions

Второе измерение по Форду/Парсонс/Куа — частота:

Triggered fitness functions запускаются по запросу — в CI, при слиянии, по расписанию. Подходят для дорогостоящих проверок (нагрузочные тесты, полное сканирование безопасности, интеграционные тесты против стейджингового окружения) или для проверок свойств, которые можно верифицировать только против собранного артефакта.

Continuous fitness functions запускаются при каждом изменении, в цикле разработки, максимально быстро. Подходят для структурных проверок (правила зависимостей, циклические зависимости, ограничения импортов), которые можно вычислить по исходному коду без сборки или деплоя.

Для проблемы нарушений границ биллинговой платформы правильны continuous fitness functions: проверка ArchUnit или ts-arch запускается в unit-тест-сьюте при каждом коммите, обнаруживая нарушение в момент его введения. Нет задержки между нарушением и обнаружением.

Нагрузочный тест, верифицирующий p99 < 200 мс при 10 000 RPM, по необходимости triggered — он требует живого окружения и занимает минуты. Запускается ежесуточно или перед релизом, а не при каждом коммите.

Реализация fitness functions: практические примеры

ArchUnit (Java) — направление зависимостей:

// Тест падает, если любой класс в billing импортирует из ordering.internal
@AnalyzeClasses(packages = "com.platform")
class ModuleBoundaryTest {
  @ArchTest
  static final ArchRule billingMayNotImportOrderingInternals =
    noClasses().that().resideInAPackage("..billing..")
      .should().dependOnClassesThat()
      .resideInAPackage("..ordering.internal..");
}

ts-arch (TypeScript) — отсутствие циклов:

// Тест падает, если существует циклическая зависимость между модулями
describe("architecture", () => {
  it("has no cyclic module dependencies", async () => {
    const result = await tsarch.FileSystem
      .fromConfig("tsconfig.json")
      .onlyFiles(["src/**/*.ts"])
      .noCycles();
    expect(result).toEqual([]);
  });
});

Бюджет задержки (assertion в unit-тесте):

it("invoice generation completes within 100ms", async () => {
  const start = performance.now();
  await billingService.generateInvoice(testOrderId);
  const elapsed = performance.now() - start;
  expect(elapsed).toBeLessThan(100);
});

Общее: каждый — тест, выдающий pass/fail. Каждый запускается в CI. Каждый ловит конкретное архитектурное свойство. Свойство ранее поддерживалось только человеческой конвенцией; fitness function превращает его в машинно-применяемый инвариант.