Перейти к содержимому

Предисловие

Archlang — язык для описания системной архитектуры в виде текста. Вы пишете .arch-файлы; каждая диаграмма, проекция, граф зависимостей и отчёт о влиянии выводятся из них. Нет отдельного инструмента для рисования, который нужно синхронизировать; нет второго источника правды, который бы расходился с первым; нет фотографии доски, которую все забыли обновить.

Если вы работали с UML-инструментами, RSM, Sparx EA или уголком Confluence с устаревшими PowerPoint-слайдами, вы уже знаете проблему, о которой эта книга. Картинки архитектуры устаревают. Исходники — нет.

Для кого эта книга

Три аудитории:

  • Инженеры и архитекторы, моделирующие систему, которой они владеют или в которой работают. Вы прочитаете главы 1-13 и, скорее всего, остановитесь там.
  • Платформенные команды, желающие определять собственные виды (payment_service, relational_db) поверх стандартной библиотеки. Вы продолжите до главы 19.
  • Разработчики инструментов, интегрирующие Archlang в редакторы, дашборды или конвейеры. Приложения в конце книги (Грамматика, Ключевые слова, Виды стандартной библиотеки, Шпаргалка) — для вас; главы дают ментальную модель за ними.

Книга предполагает, что вы писали код раньше. Не предполагает, что вы пользовались языком описания архитектуры — большинство не пользовались.

Три идеи

Большая часть Archlang следует напрямую из трёх принципов. Каждый необычен настолько, что заслуживает названия с самого начала.

1. Архитектура определяется, а не рисуется. Диаграмма — это проекция модели, как график — проекция таблицы. Вы не редактируете диаграмму, чтобы изменить систему; вы редактируете исходник. Диаграмма обновится на следующем рендере.

2. Типы — это шаблоны форм, а не классы. Когда вы объявляете type module service { required cascade team }, вы не строите иерархию классов. Вы определяете, что каждый экземпляр service в вашем рабочем пространстве обязан заполнить. Экземпляр — это заполненная форма. Главы 14-18 раскрывают это.

3. Изменение — полноправный объект. У архитектуры есть история. Ветки — будущие состояния; коммиты — решения; диффы — дельты архитектуры. Стабильные идентификаторы закрепляют сущность сквозь переименования, так что рефакторинг никогда не выглядит как «всё удалили и добавили». Глава 14 — там, где это всё сходится.

Если что-то из этого звучит неправильно на первый взгляд — это ожидаемо. У каждой идеи есть глава, которая её обосновывает.

Чем эта книга не является

  • Не пособие по инструментам диаграмм. Archlang производит диаграммы; он ими не управляется.
  • Не CMDB. Он фиксирует, чем ваша архитектура является, а не что сейчас выполняется.
  • Не среда выполнения. Он не исполняет процессы; он их описывает.
  • Не язык программирования. Нет функций, нет значений кроме идентификаторов и строк, нет системы типов для полей. Выразительная мощь живёт в метамодели.

Как читать

Главы пронумерованы и предназначены для чтения по порядку, по крайней мере в первый раз. Каждая вводит понятия, на которых строится следующая. Главы про образ мышления (14, 17) длиннее остальных — они того стоят.

Если вы используете только виды, определённые стандартной библиотекой или вашей платформенной командой, можно остановиться в конце Главы 14 и вернуться к части IV, когда понадобится определить собственный вид.

Приложения в конце (Грамматика, Ключевые слова, Виды стандартной библиотеки, Шпаргалка) — отдельные. Они для справки, когда вы уже знаете, что ищете.

Что дальше

Глава 1: Установка → — запустить рабочее пространство.