Типизированный язык для модулей, интерфейсов и процессов. Один бесконечный холст: от всей системы до отдельного интерфейса.
Ранний предпросмотр, продукт активно развивается. Можно пробовать, но в продакшене использовать пока рано. Оценить готовность Оставить отзыв
Поведение во времени. Процесс задействует интерфейсы между модулями — и именно отсюда берутся связи. Вы описываете поток, а связи выводятся из него автоматически.
process Checkout {
Customer > Orders.placeOrder
Orders > Payments.authorize
Payments > Ledger.record
}У каждой связи есть причина: какой процесс, какой шаг, зачем.
Части системы. Вписывайте их без ограничений друг в друга и задавайте для каждого свой тип и поля — сервис, базу данных, внешнего подрядчика.
service Payments {
aspect team: "Risk"
module Gateway
module Ledger
}Те же прямоугольники, что и в C4, — но с произвольной глубиной вложенности и собственными типами.
Как частям разрешено общаться друг с другом: именованные типизированные точки, которые открывает модуль. Пересечь границу можно только через такую точку, и каждый интерфейс сам объявляет свой протокол — синхронный или асинхронный, а не угадывается по способу передачи данных.
service Payments {
rest_create charge {
aspect path: "/v1/charges"
rate_limit: "100/s"
openapi: "https://api.payments.acme/openapi.json"
}
}Язык взаимодействия.
Представление — это срез единой модели: процесс, команда, вопрос. Модель остаётся единственной истиной, а каждая диаграмма — одна из её проекций.
view SecurityZones { group by @@security.zone }
view NetworkMap { group by @@network.segment }Меняйте вопрос, а не модель.
Готовый веб-компонент — просто подключите. Живые диаграммы на любой HTML-странице.
Открыть viewerЧистый лист для наброска. Опишите модуль, посмотрите на диаграмму, поделитесь ссылкой.
Открыть scratchПереименование, подсказки при наведении, автодополнение, форматирование при сохранении и подсветка ошибок прямо в редакторе.
Установить для VS CodeРаботает в IDEA, WebStorm, GoLand, Rider, PyCharm. Те же возможности, что и в VS Code.
Установить для IntelliJПроверка, форматирование, сравнение версий. Прерывайте сборку в CI, если архитектура нарушена.
Установить через npmСоздавайте, проверяйте и синхронизируйте файлы .arch вместе с Claude Code — пять навыков в одной установке.
Установить через npxОблачная платформа с несколькими рабочими пространствами и ревью изменений по каждой ветке.
Записаться в лист ожиданияВетки показывают будущие состояния системы, а каждая фиксация изменений — это принятое решение. Проверка запроса на слияние становится, по сути, проверкой архитектуры. Стабильные идентификаторы (#xyz) сохраняют привязку к каждому узлу при любом переименовании, поэтому ссылки между модулями не ломаются.
orders.arch service #q7f2 Orders {
aspect team: "Commerce"
"Владеет жизненным циклом заказа.
Публикует события, которые читает [[#m4k9]]."
kafka orderPlaced
}
service #m4k9 Shipping {
aspect team: "Fulfillment"
rest_create createShipment
}Один синтаксис работает на обоих концах шкалы. Одна стрелка — Orders > Payments — уже готовая модель; тот же язык масштабируется до тысяч сервисов с владельцами, доменами, событиями и хранилищами. Ничего не нужно переписывать, менять инструмент или упираться в потолок возможностей. Проверено на моделях со 100 000 узлов.
scale.arch // пол: уже законченная модель сама по себе
Orders > Payments
// …тот же язык, с полной детализацией
service Orders {
aspect team: "Commerce"
rest_create place
kafka orderPlaced
}Опишите поток — получите граф. Процессы — единственный источник истины о том, кто кого вызывает. Граф вызовов, зона поражения и критический путь не рисуются стрелками вручную, а выводятся из самого поведения.
checkout.arch actor Customer
service Orders { aspect team: "Commerce"; rest_create placeOrder }
service Payments { aspect team: "Risk"; rest_create authorize }
service Ledger { aspect team: "Finance"; kafka record }
process Checkout {
Customer > Orders.placeOrder
Orders > Payments.authorize
Payments > Ledger.record
}Незавершённость здесь предусмотрена языком, а не считается ошибкой. Ключевое слово required помечает обязательные поля; экземпляр либо заполняет их, либо явно от них отказывается. Набросайте первый этап, выпустите, остальное доделаете позже — валидатор точно укажет, где остались пробелы.
payments.arch // тип, который требует аспект compliance
type service audited {
required aspect compliance
}
audited Payments {
aspect team: "Risk"
rest_create charge
// aspect compliance не задан: проверка укажет
// на этот пропуск, но модель всё равно рисуется и коммитится
}Пометьте каждый модуль аспектами — зона безопасности, сегмент сети, команда — а затем задайте представление под каждый ракурс: сгруппированные диаграммы, BPMN-дорожки, потоки с разметкой задержек. Все представления читают один и тот же источник, поэтому диаграмма безопасности и диаграмма сети никогда не разойдутся между собой.
payments.arch service Payments {
aspect {
team: "Risk"
security.zone: "PCI"
network.segment: "DMZ"
}
rest_create authorize { latency: 200ms }
}
view SecurityZones { group by @@security.zone }
view NetworkMap { group by @@network.segment }
view CheckoutOps { flow Checkout bpmn { lane by @@team } }Типы здесь не зашиты в фиксированную схему: вы задаете их сами. Возьмите тип из stdlib, уточните под свой домен, добавьте обязательные поля, а cascade протолкнет общие значения вниз по дереву. Экземпляры наследуют всю цепочку целиком: можно переопределить или отбросить что угодно. Любой запрос можно превратить в политику, и `archlang check` обеспечит её соблюдение по всему проекту.
types.arch // stdlib определяет необязательный `aspect team`; обязательное владение —
// это опциональная политика arch.policy OwnershipCoverage.
type service pci_service {
required aspect compliance
aspect { security.zone: "PCI" }
}
// экземпляр наследует всю цепочку
pci_service Payments {
aspect {
team: "Risk"
compliance: "PCI-DSS v4"
}
}
// обеспечьте это в рамках всего проекта — archlang check прерывает сборку при пропуске
policy OwnershipCoverage {
forbid service and where (not @@team)
}Модуль, интерфейс, процесс, представление — вот и все фиксированные примитивы языка. Даже то, как рисуется узел, решаете вы сами. Зарегистрируйте свой элемент для типа целиком или задайте HTML-шаблон прямо внутри одного узла — JS для этого не обязателен.
package.archspace // регистрирует ваши элементы
widgets: "./widgets.js"platform.arch // тип модуля, которого ядро не поставляло, рисует ваш <arch-queue>
type module queue {
cascade widget: arch-queue
}
queue OrderBus { kafka orderPlaced }
// без JS: оформите узел на месте; {{...}} читает тело
service Payments {
aspect team: "Risk"
widget: "<b class='text-arch-300'>{{name}}</b> · {{aspects.team}}"
}Вы начинаете не с пустой метамодели. В stdlib уже есть готовые типы для всех слоев: базовые примитивы, модули и устройства, весь backend-стек, примитивы диаграмм и облачные каталоги по провайдерам. У каждого разумные значения по умолчанию и свой виджет. Импортируйте нужное, остальное наследуйте. Все опционально и расширяемо: можете убрать библиотеку из комплекта и поставить свои типы, иконки и виджеты.
Дело не в том, какой инструмент рисует самые красивые прямоугольники, а в том, что служит источником истины и откуда берутся связи между элементами. В большинстве инструментов связи приходится рисовать вручную. ArchLang выводит их из поведения системы.
Lucid, Miro, Excalidraw, diagrams.net
Картинка это не данные. Ее нельзя запросить, посчитать радиус влияния или проверить правило вроде «у каждого сервиса есть владелец». И каждое представление это отдельный артефакт, который приходится синхронизировать вручную.
Где они сильны: можно рисовать что угодно, а не только программные системы — никакого синтаксиса, на свободном холсте и с совместным редактированием в реальном времени.
Mermaid, PlantUML, D2
Это текст, поэтому изменения в нём видны, но по сути это всё равно картинка, а не модель. Скрипт описывает, как рисовать, а не что есть на самом деле: нет типов, запросов, правил, и одну и ту же систему приходится собирать заново в каждой диаграмме.
Где они сильны: доступность без всякой настройки. Блок кода рендерится прямо в GitHub, GitLab и большинстве вики — без установки какого-либо инструментария.
C4 / Structurizr, ArchiMate
По духу ближе всего: много представлений из одного источника. Но связи задаются руками, а не выводятся из поведения, так что граф правдив ровно настолько, насколько кто-то не забыл его обновить. И метамодель фиксированная: свои типы, обязательные поля и иерархию не задать.
Где они сильны: зрелость и широкое распространение — устоявшаяся нотация, богатая экосистема и интеграции, которых у ArchLang пока нет.
одна типизированная модель
Один типизированный источник с полной историей изменений. Связи не рисуются вручную, а выводятся из процессов. Каждое представление, каждая проверка и сравнение веток строятся на основе одной и той же модели.
Компромиссы: заточено под архитектуру программных систем; придётся выучить типизированный язык вместо перетаскивания блоков мышкой; а для связей нужен описанный процесс, поэтому быстрый набросок сделать сложнее.
| Lucid / Miro | Mermaid / PlantUML | C4 / Structurizr | ArchLang | |
|---|---|---|---|---|
| Хранится как текст в git | ✗ | ✓ | ✓ | ✓ |
| Типизированная модель с валидацией | ✗ | ✗ | ~ | ✓ |
| Связи выводятся из поведения | ✗ | ✗ | ✗ | ✓ |
| Много представлений из одного источника | ✗ | ✗ | ✓ | ✓ |
| Правила governance применяются автоматически (политики) | ✗ | ✗ | ✗ | ✓ |
| Архитектурный diff, а не просто текстовый | ✗ | ✗ | ~ | ✓ |
| Рендерится прямо в GitHub и wiki | ✗ | ✓ | ✗ | ~ |
| Рисуйте свободно, без синтаксиса для изучения | ✓ | ✗ | ✗ | ✗ |
Предпросмотр в активной разработке. Интерфейсы и поведение могут меняться от версии к версии.
Оставить отзывНет. Неполные модели — это нормально, так и задумано: опишите несколько модулей, закоммитьте, отрисуйте — а остальное доделаете позже. Ключевое слово required помечает обязательные поля, и валидатор точно укажет на пробелы, но не заблокирует ни отрисовку, ни коммит.
Нет, это другой уровень. Там один скрипт даёт одну диаграмму. ArchLang это типизированная модель: один версионируемый источник даёт много производных представлений, проверок и сравнений между версиями. Диаграмма тут результат, а не артефакт, который вы правите руками.
Рисунок устаревает в тот же момент, когда меняется код, и сравнить его версии невозможно. Здесь же архитектура — текст, живущий в git: работают ветки, предпросмотр пул-реквестов, история изменений по авторам и настоящее сравнение «было — стало».
Только вручную, не импортом. В этих инструментах связи рисуются напрямую, а ArchLang выводит их из процессов, поэтому честного механического переноса нет: в исходной диаграмме просто нет поведения, из которого рождаются связи. Метамодель хорошо ложится на уровни C4, а в документации есть пошаговая инструкция по ручному переносу из инструментов корпоративной архитектуры.
Создайте подтип любого типа и доработайте его под себя — либо вовсе откажитесь от встроенной библиотеки и подключите свои типы, иконки и виджеты. Фиксированы только четыре базовых примитива: модуль, интерфейс, процесс и представление.
Пока нет. Это ранняя версия, разработка активно продолжается, и интерфейсы ещё могут меняться от версии к версии. Пробуйте, экспериментируйте и присылайте отзывы — статус готовности по каждому компоненту указан в таблице выше.