Architecture As Code Tools (aact)

CLI и библиотека для валидации, анализа и генерации архитектуры микросервисных систем, описанной "as Code" (PlantUML C4, Structurizr).

Инструменты для работы с архитектурой в формате "as Code":

1. Код и примеры покрытия тестами микросервисной архитектуры, описанной в plantuml (#)
2. Автогенерация архитектуры (#)
3. Тестирование архитектуры модульного монолита (#)

Планы развития инструментов и репозитория. PullRequest'ы и Issues'ы приветствуются.

Справочник принципов и паттернов проектирования с примерами покрытия их тестами (пополняется...)

Телеграм-канал: Архитектура распределённых систем

aact можно использовать двумя способами: как CLI (npx aact check, авто-фикс, генерация артефактов) или как библиотеку (импортировать checkAcl, analyzeArchitecture и пр. в свои тесты на vitest/jest). CLI — ниже, library-режим — в соответствующем разделе.

Quick Start (CLI)

В пустой папке:

# Создаёт aact.config.ts и стартовый architecture.puml с одним
# умышленным нарушением, чтобы было что чинить
npx aact init

# Покажет 1 нарушение CRUD-правила (orders → orders_db напрямую)
npx aact check

# Применит auto-fix: добавит orders_repo как посредника к БД
npx aact check --fix

# Снова чисто
npx aact check

После этого правь architecture.puml под свою систему — синтаксис C4-PlantUML.

Остальные команды

npx aact check --dry-run             # preview auto-fix без записи
npx aact analyze                     # coupling/cohesion метрики
npx aact generate --format plantuml  # сгенерировать .puml из источника
npx aact generate --format kubernetes

Для structurizr укажите source.writePath в aact.config.ts — путь к workspace.dsl, в который пишутся правки от --fix.

Что создаёт aact init

Два файла рядом:

• aact.config.ts — настройки источника и набор включённых правил. Использует import type { AactConfig } — рантайм-резолва пакета не происходит, поэтому npx aact check работает без npm install aact.
• architecture.puml — стартовая C4-схема с одним сервисом, одной БД и умышленным нарушением CRUD-правила. Замени на свою.

// aact.config.ts (фрагмент)
import type { AactConfig } from "aact";

const config: AactConfig = {
  source: {
    type: "plantuml", // "plantuml" | "structurizr"
    path: "./architecture.puml",
  },
  rules: {
    acl: true,
    acyclic: true,
    apiGateway: true,
    crud: true,
    dbPerService: true,
    cohesion: true,
    stableDependencies: true,
    commonReuse: true,
  },
};

export default config;

Использование как библиотеки

import {
  loadPlantumlElements,
  mapContainersFromPlantumlElements,
  checkAcl,
  checkAcyclic,
  checkCrud,
  analyzeArchitecture,
} from "aact";

const elements = await loadPlantumlElements("architecture.puml");
const model = mapContainersFromPlantumlElements(elements);

// Проверка правил
const aclViolations = checkAcl(model.allContainers);
const cyclicViolations = checkAcyclic(model.allContainers);

// Анализ метрик
const { report } = analyzeArchitecture(model);
console.log(`Elements: ${report.elementsCount}`);

Примеры

Запускаемые из коробки (склонируй репо, cd examples/<name>, npx aact check):

• examples/ecommerce-structurizr/ — Structurizr-источник с workspace.json + workspace.dsl, полный цикл правил и auto-fix.
• examples/violations-demo/ — мини-набор умышленных нарушений по каждому правилу — чтобы посмотреть, как выглядит вывод и какие правки предлагает --fix.

Тестовые сценарии (для разработчиков пакета, запускаются через vitest):

• examples/banking-plantuml/ и examples/microservices-structurizr/ — интеграционные тесты архитектуры из resources/.

Документация

• Справочник паттернов — принципы и паттерны с примерами тестов
• ADR — Architecture Decision Records
• Roadmap — планы развития

Публичные материалы

Раз архитектура — «as Code», почему бы её не покрыть тестами?!

https://www.youtube.com/watch?v=POIbWZh68Cg       https://www.youtube.com/watch?v=tZ-FQeObSjY

Статья на Хабре

Автогенерация архитектуры

https://www.youtube.com/watch?v=fb2UjqjHGUE

Покрытие архитектуры тестами

Что это, какую боль решает, и с чего начать?

Раз архитектура — «as Code», почему бы её не покрыть тестами?!

Тема идеи и данный открытый репозиторий вызвал неожиданную волну позитивных отзывов о попадании в яблочко болей и о применимости и полезности решения :)

Подход помогает решить проблемы неактуальности, декларативности и отсутствия контроля ИТ-архитектур и инфраструктуры (ограничение и требование — архитектура и инфраструктура должны быть "as code").

Тесты проверяют 2 больших блока:

• актуальность архитектуры реальному работающему в продакшне решению
• соответствие "нарисованной" архитектуры выбранным принципам и паттернам проектирования

Подробнее о подходе, решаемых проблемах, схеме работы представленного в репозитории примера и проверяемых в тестах репозитория принципах — на слайдах.

Схема работы

Визуализация примера автоматически проверяемого принципа (отсутствие бизнес-логики в CRUD-сервисах)

Пример архитектуры, которую покроем тестами

Пример тестов

1. find diff in configs and uml containers — проверяет актуальность списка микросервисов на архитектуре и в конфигурации инфраструктуры
2. find diff in configs and uml dependencies — проверяет актуальность зависимостей (связей) микросервисов на архитектуре и в конфигурации инфраструктуры
3. check that urls and topics from relations exist in config — проверяет соответствие между параметрами связей микросервисов (REST-урлы, топики kafka) на архитектуре и в конфигурации инфраструктуры
4. only acl can depend on external systems — проверяет, что не нарушен выбранный принцип построения интеграций с внешними системами только через ACL (Anti Corruption Layer). Проверяет, что только acl-микросервисы имеют зависимости от внешних систем.
5. connect to external systems only by API Gateway or kafka — проверяет, что все внешние интеграции идут через API Gateway или через kafka

Автогенерация архитектуры

Генерация архитектуры из описанной «as Code» инфраструктуры

Сравнение белковой составленной вручную архитектуры и сгенерированной.

Ручная:

Сгенерированная:

Тестирование модульного монолита

Тестами можно покрывать не только архитектуру микросервисов, но архитектуру монолитов, особенно, если они модульные.

• Тест архитектуры модульного монолита на C#

Тестирование на основе информации из кода

Информацию об архитектуре реализованной системы можно извлечь и из ее кода, особенно, если он написан качественно;)

• Извлечение информации об архитектуры системы из ее кода