diff --git a/RU/asciidoc/arc42-template.adoc b/RU/asciidoc/arc42-template.adoc
new file mode 100644
index 0000000..b81171c
--- /dev/null
+++ b/RU/asciidoc/arc42-template.adoc
@@ -0,0 +1,100 @@
+// header file for arc42-template,
+// including all help texts
+//
+// ====================================
+
+// configure EN settings for asciidoc
+include::src/config.adoc[]
+
+= image:arc42-logo.png[arc42] Шаблон
+:revnumber: 8.2 RU
+:revdate: Январь 2023
+:revremark: (основана на версии AsciiDoc)
+// toc-title definition MUST follow document title without blank line!
+:toc-title: Оглавление
+
+//additional style for arc42 help callouts
+ifdef::backend-html5[]
+++++
+<style>
+.arc42help {font-size:small; width: 14px; height: 16px; overflow: hidden; position: absolute; right: 0; padding: 2px 0 3px 2px;}
+.arc42help::before {content: "?";}
+.arc42help:hover {width:auto; height: auto; z-index: 100; padding: 10px;}
+.arc42help:hover::before {content: "";}
+@media print {
+	.arc42help {display:none;}
+}
+</style>
+++++
+endif::backend-html5[]
+
+
+include::src/about-arc42.adoc[]
+
+// horizontal line
+***
+
+[role="arc42help"]
+****
+[NOTE]
+====
+Эта версия шаблона содержит подсказки и пояснения.
+Используйте для ознакомления с arc42 и понимания концепций.
+Для документирования собственной системы лучше использовать _простую(plain)_ версию.
+
+====
+****
+
+
+// numbering from here on
+:numbered:
+
+<<<<
+// 1. Introduction and Goals
+include::src/01_introduction_and_goals.adoc[]
+
+<<<<
+// 2. Architecture Constraints
+include::src/02_architecture_constraints.adoc[]
+
+<<<<
+// 3. Context and Scope
+include::src/03_context_and_scope.adoc[]
+
+<<<<
+// 4. Solution Strategy
+include::src/04_solution_strategy.adoc[]
+
+<<<<
+// 5. Building Block View
+include::src/05_building_block_view.adoc[]
+
+<<<<
+// 6. Runtime View
+include::src/06_runtime_view.adoc[]
+
+<<<<
+// 7. Deployment View
+include::src/07_deployment_view.adoc[]
+
+<<<<
+// 8. Concepts
+include::src/08_concepts.adoc[]
+
+<<<<
+// 9. Architecture Decisions
+include::src/09_architecture_decisions.adoc[]
+
+<<<<
+// 10. Quality Requirements
+include::src/10_quality_requirements.adoc[]
+
+<<<<
+// 11. Technical Risks
+include::src/11_technical_risks.adoc[]
+
+<<<<
+// 12. Glossary
+include::src/12_glossary.adoc[]
+
+
diff --git a/RU/asciidoc/src/01_introduction_and_goals.adoc b/RU/asciidoc/src/01_introduction_and_goals.adoc
new file mode 100644
index 0000000..384512d
--- /dev/null
+++ b/RU/asciidoc/src/01_introduction_and_goals.adoc
@@ -0,0 +1,92 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-introduction-and-goals]]
+== Введение и цели
+
+[role="arc42help"]
+****
+Описывает соответствующие требования и движущие силы, которые должны учитывать архитекторы программного обеспечения и команда разработчиков.
+К ним относятся
+
+* основные бизнес-цели,
+* важные особенности,
+* основные функциональные требования,
+* цели в области качества архитектуры и
+* соответствующие заинтересованные стороны и их ожидания
+****
+
+=== Обзор требований
+
+[role="arc42help"]
+****
+.Содержание
+Краткое описание функциональных требований, движущих сил, выжимка требований. Ссылка на (возможно, уже существующие) документы с требованиями
+(с номером версии и информацией, где ее найти).
+
+.Мотивация
+С точки зрения конечных пользователей система создается или модифицируется, чтобы
+улучшить поддержку деловой активности и/или улучшить качество.
+
+.Форма
+Краткое текстовое описание, вероятно, в табличном формате варианта использования.
+Если существуют документы с требованиями, этот обзор должен ссылаться на эти документы.
+
+Сделайте эти выдержки как можно короче. Соблюдайте баланс читабельности этого документа с потенциальной избыточностью по отношению к документам с требованиями
+
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-1/[Введение и цели] в документации arc42.
+
+****
+
+=== Цели по качеству
+
+[role="arc42help"]
+****
+.Содержание
+Три (максимум пять) главных целей в области качества для архитектуры, выполнение которых имеет первостепенное значение для основных заинтересованных сторон.
+Здесь действительно имеются в виду цели качества для архитектуры. Не путайте их с целями проекта.
+Они необязательно совпадают.
+
+Рассмотрите этот обзор потенциальных тем (на основе стандарта ISO 25010):
+
+image::01_2_iso-25010-topics-EN.drawio.png["Категории требований по качеству"]
+
+.Мотивация
+Вы должны знать цели в области качества наиболее важных заинтересованных сторон, поскольку они будут влиять на фундаментальные архитектурные решения.
+Убедитесь, что вы очень конкретно говорите об этих качествах, избегайте модных словечек.
+Если вы как архитектор не знаете, как будет оцениваться качество вашей работы...
+
+.Форма
+Таблица с целями по качеству и конкретными сценариями, упорядоченными по приоритетам
+****
+
+=== Заинтересованные стороны
+
+[role="arc42help"]
+****
+.Содержание
+Подробный обзор заинтересованных сторон системы, т. е. всех лиц, ролей или организаций, которые
+
+* должны знать архитектуру
+* должны быть уверены в архитектуре
+* работать с архитектурой или с кодом
+* нуждаются в архитектурной документации для своей работы
+* должны принимать решения о системе или ее развитии
+
+.Мотивация
+Вы должны знать все стороны, участвующие в разработке системы или затронутые системой.
+В противном случае вы можете получить неприятные сюрпризы позже в процессе разработки.
+Эти заинтересованные стороны определяют степень и уровень детализации вашей работы и ее результатов.
+
+.Форма
+Таблица именами людей, их ролями и ожиданиями в отношении архитектуры и ее документации.
+****
+
+[options="header",cols="1,2,2"]
+|===
+|Роль/Имя|Контактные данные|Ожидания
+| _<Роль-1>_ | _<Контактные-данные-1>_ | _<Ожидания-1>_
+| _<Роль-2>_ | _<Контактные-данные-2>_ | _<Ожидания-2>_
+|===
\ No newline at end of file
diff --git a/RU/asciidoc/src/02_architecture_constraints.adoc b/RU/asciidoc/src/02_architecture_constraints.adoc
new file mode 100644
index 0000000..b1dcba1
--- /dev/null
+++ b/RU/asciidoc/src/02_architecture_constraints.adoc
@@ -0,0 +1,27 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-architecture-constraints]]
+== Архитектурные ограничения
+
+
+[role="arc42help"]
+****
+.Содержание
+Любое требование, ограничивающее архитекторов программного обеспечения в их свободе проектирования и решений по реализации или в принятии решений о процессе разработки. Эти ограничения иногда выходят за рамки отдельных систем и действительны для целых организаций и компаний.
+
+.Мотивация
+Архитекторы должны точно знать, где они свободны в своих проектных решениях, а где должны придерживаться ограничений.
+С ограничениями всегда нужно иметь дело; хотя они могут быть предметом переговоров.
+
+.Форма
+Простые таблицы ограничений с пояснениями.
+При необходимости вы можете разделить их на
+технические ограничения, организационные и политические ограничения и
+соглашения (например, рекомендации по программированию или управлению версиями, документация или соглашения о наименованиях)
+
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-2/[Архитектурные ограничения] в документации arc42.
+
+****
diff --git a/RU/asciidoc/src/03_context_and_scope.adoc b/RU/asciidoc/src/03_context_and_scope.adoc
new file mode 100644
index 0000000..86cd487
--- /dev/null
+++ b/RU/asciidoc/src/03_context_and_scope.adoc
@@ -0,0 +1,74 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-context-and-scope]]
+== Контекст и рамки
+
+
+[role="arc42help"]
+****
+.Содержание
+
+Контекст и область действия — как следует из названия — разграничивают вашу систему (ее рамки) от всех партнеров с которыми она коммуницирует (соседние системы и пользователи, т.е. контекст вашей системы). Таким образом, он определяет внешние интерфейсы.
+
+При необходимости различайте бизнес-контекст (специфические для предметной области входы и выходы) и технический контекст (каналы, протоколы, аппаратное обеспечение).
+
+.Мотивация
+Интерфейсы домена и технические интерфейсы для коммуникационных партнеров являются одними из наиболее важных аспектов вашей системы. Убедитесь, что вы их полностью понимаете.
+
+.Форма
+Различные варианты:
+
+* Контекстные диаграммы
+* Списки коммуникационных партнеров и их интерфейсов.
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-3/[Context and Scope] в документации arc42.
+
+****
+
+
+=== Бизнес контекст
+
+[role="arc42help"]
+****
+.Содержание
+Спецификация *всех* коммуникационных партнеров (пользователи, ИТ-системы, ...) с пояснениями входных и выходных данных или интерфейсов, специфичных для предметной области.
+При желании вы можете добавить специфичные для домена форматы или протоколы связи.
+
+.Мотивация
+Все заинтересованные стороны должны понимать, какими данными система обменивается со средой.
+
+.Форма
+Все виды диаграмм, изображающих систему в виде черного ящика и определяющих интерфейсы домена для коммуникационных партнеров.
+
+В качестве альтернативы (или дополнительно) можно использовать таблицу.
+Заголовок таблицы — это имя вашей системы, три столбца содержат имя партнера, с которым происходит коммуникация, входы и выходы.
+
+****
+
+**<Диаграмма или таблица>**
+
+**<необязательно: объяснение внешних доменных интерфейсов>**
+
+=== Технический контекст
+
+[role="arc42help"]
+****
+.Содержание
+Технические интерфейсы (каналы и среды передачи), связывающие вашу систему с окружающей средой. Кроме того, сопоставление ввода/вывода, специфичного для предметной области, с каналами, то есть объяснение, какой ввод/вывод использует какой канал.
+
+.Мотивация
+Многие заинтересованные стороны принимают архитектурные решения на основе технических интерфейсов между системой и ее контекстом. Зачастую разработчики инфраструктуры или оборудования выбирают эти технические интерфейсы.
+
+.Форма
+Например, диаграмма развертывания UML, описывающая каналы к соседним системам,
+вместе с таблицей сопоставления, показывающей взаимосвязь между каналами и вводом/выводом.
+
+****
+
+**<Диаграмма или таблица>**
+
+**<необязательно: Пояснения к техническим интерфейсам>**
+
+**<Сопоставление ввода/вывода с каналами>**
diff --git a/RU/asciidoc/src/04_solution_strategy.adoc b/RU/asciidoc/src/04_solution_strategy.adoc
new file mode 100644
index 0000000..fa06bd8
--- /dev/null
+++ b/RU/asciidoc/src/04_solution_strategy.adoc
@@ -0,0 +1,32 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-solution-strategy]]
+== Стратегия решения
+
+
+[role="arc42help"]
+****
+.Содержание
+
+Краткое изложение и объяснение основных решений и стратегии, формирующих архитектуру системы. Они включают
+
+* технологические решения
+* решения о декомпозиции системы на верхнем уровне, т.е. использование архитектурного шаблона или шаблона проектирования
+* решения о том, как достичь ключевых целей в области качества
+* соответствующие организационные решения, т.е. выбор процесса разработки или делегирование определенных задач третьим лицам.
+
+.Мотивация
+Эти решения ложатся в основу вашей архитектуры. На них опираются многие другие более специфические решения или правила реализации.
+
+.Форма
+Объяснения таких ключевых решений должны быть короткими.
+
+Мотивируйте решение (и почему было решено именно так)
+на основе постановки задачи, целей в области качества и ключевых ограничений.
+Подробности см. в следующих разделах.
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-4/[Стратегия решения] в документации arc42.
+
+****
diff --git a/RU/asciidoc/src/05_building_block_view.adoc b/RU/asciidoc/src/05_building_block_view.adoc
new file mode 100644
index 0000000..41bea06
--- /dev/null
+++ b/RU/asciidoc/src/05_building_block_view.adoc
@@ -0,0 +1,213 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-building-block-view]]
+
+
+== Представление строительных блоков
+
+[role="arc42help"]
+****
+.Содержание
+Представление строительных блоков показывает статическую декомпозицию системы на строительные блоки (модули, компоненты, подсистемы, классы, интерфейсы, пакеты, библиотеки, фреймворки, слои, партиции, уровни, функции, макросы, операции, структуры данных, ...) а также их зависимости (отношения, ассоциации, ...)
+
+Это представление является обязательным для любой архитектурной документации.
+По аналогии с домом это _план этажа_.
+
+.Мотивация
+Поддерживайте структуру исходного кода понятной с помощью абстракций.
+
+Это позволит вам общаться с заинтересованными лицами на абстрактном уровне, не раскрывая деталей реализации.
+
+.Форма
+Представление стандартных блоков представляет собой иерархическую коллекцию черных и белых ящиков.
+(см. рисунок ниже) и их описания.
+
+image::05_building_blocks-EN.png["Иерархия строительных блоков"]
+
+*Уровень 1* представляет собой описание всей системы в виде «белого ящика» вместе с описаниями всех содержащихся строительных блоков в виде «черных ящиков».
+
+*Уровень 2* раскрывает детали некоторых строительных блоков уровня 1.
+Таким образом, он содержит описание «белого ящика» выбранных строительных блоков уровня 1 вместе с описанием их внутренних строительных блоков как «черных ящиков».
+
+*Уровень 3* увеличивает масштаб выбранных строительных блоков уровня 2 и так далее.
+
+.Дальнейшая информация
+
+Смотрите https://docs.arc42.org/section-5/[Представление строительных блоков] в документации arc42.
+
+****
+
+=== Система в общем («белый ящик»)
+
+[role="arc42help"]
+****
+Здесь вы описываете декомпозицию всей системы, используя следующий шаблон белого ящика. Описание содержит
+
+* обзорную схему
+* мотивацию декомпозиции
+* описания содержащихся строительных блоков («черный ящик»). Для них мы предлагаем альтернативы:
+
+** используйте _одну_ таблицу для краткого и практичного обзора всех содержащихся строительных блоков и их интерфейсов
+** используйте список описаний составных частей «черного ящика» в соответствии с шаблоном «черного ящика» (см. ниже).
+
+В зависимости от выбранного вами инструмента этот список может состоять из подглав (в текстовых файлах), подстраниц (в Wiki) или вложенных элементов (в инструменте моделирования).
+
+
+* (необязательно:) важные интерфейсы, которые не объясняются в шаблонах «черного ящика» строительных блоков, но очень важны для понимания белого «ящика».
+Поскольку существует так много способов указать интерфейсы, почему бы не предоставить для них специальный шаблон.
+В худшем случае вам придется указать и описать синтаксис, семантику, протоколы, обработку ошибок,
+ограничения, версии, качества, необходимые совместимости и многое другое.
+В лучшем случае вам сойдут с рук примеры или простые подписи.
+
+****
+
+_**<Обзорная диаграмма>**_
+
+Мотивация::
+
+_<текстовое объяснение>_
+
+
+Содержащиеся строительные блоки::
+_<Описание строительных блоков (черные ящики)>_
+
+Важные интерфейсы::
+_<Описание важных интерфейсов>_
+
+[role="arc42help"]
+****
+
+Вставьте свои объяснения черных «ящиков» из уровня 1:
+
+Если вы используете табличную форму, вы будете описывать только свои черные ящики с именем и
+ответственности по следующей схеме:
+
+[cols="1,2" options="header"]
+|===
+| **Название** | **Ответственность**
+| _<Черный ящик 1>_ | _<Текст>_
+| _<Черный ящик 2>_ | _<Текст>_
+|===
+
+
+Если вы используете список описаний «черного ящика», то вы заполняете отдельный шаблон «черного ящика» для каждого важного стандартного блока.
+Его заголовок — название черного ящика.
+
+****
+
+
+==== <Название черного ящика 1>
+
+[role="arc42help"]
+****
+
+Здесь вы описываете <черный ящик 1>
+в соответствии со следующим шаблоном:
+
+* Цель/ответственность
+* Интерфейс(ы), если они не описаны отдельными абзацами. Эти интерфейсы могут включать качества и характеристики производительности.
+* (Необязательно) Характеристики качества/производительности «черного ящика», например, доступность, поведение во время выполнения, ....
+* (Необязательно) расположение каталога/файла
+* (Необязательно) Выполненные требования (если вам нужна прослеживаемость к требованиям).
+* (Необязательно) Открытые вопросы/проблемы/риски
+
+****
+
+_<Цель/обязанности>_
+
+_<Интерфейс(ы)>_
+
+_<(Необязательно) Характеристики качества/производительности>_
+
+_<(Необязательно) Папка/Расположение файла>_
+
+_<(Необязательно) Выполненные требования>_
+
+_<(необязательно) Открытые проблемы/проблемы/риски>_
+
+
+
+
+==== <Название черного ящика 2>
+
+_<шаблон черного ящика>_
+
+==== <Название черного ящика n>
+
+_<шаблон черного ящика>_
+
+
+==== <Название интерфейса 1>
+
+...
+
+==== <Название интерфейса m>
+
+
+
+
+=== Уровень 2
+
+[role="arc42help"]
+****
+Здесь вы можете указать внутреннюю структуру (некоторых) строительных блоков первого уровня в виде «белого ящика».
+
+Вы должны решить, какие строительные блоки вашей системы достаточно важны, чтобы оправдать такое подробное описание.
+Пожалуйста, предпочтите релевантность полноте. Укажите важные, неожиданные, рискованные, сложные или изменчивые строительные блоки.
+Исключите нормальные, простые, скучные или стандартизированные части вашей системы.
+****
+
+==== Белый ящик _<строительный блок 1>_
+
+[role="arc42help"]
+****
+...описывает внутреннюю структуру _строительного блока 1_.
+
+****
+
+_<шаблон белого ящика>_
+
+==== Белый ящик _<строительный блок 2>_
+
+
+_<шаблон белого ящика>_
+
+...
+
+==== Белый ящик _<строительный блок m>_
+
+
+_<шаблон белого ящика>_
+
+
+
+=== Уровень 3
+
+[role="arc42help"]
+****
+
+Если вам нужны более подробные уровни вашей архитектуры, скопируйте эту
+часть arc42 для дополнительных уровней.
+****
+
+
+==== Белый ящик <_строительный блок x.1_>
+
+[role="arc42help"]
+****
+Описывает внутреннюю структуру _строительного блока x.1_.
+****
+
+
+_<шаблон белого ящика>_
+
+
+==== Белый ящик <_строительный блок x.2_>
+
+_<шаблон белого ящика>_
+
+
+
+==== Белый ящик <_строительный блок y.1_>
+
+_<шаблон белого ящика>_
diff --git a/RU/asciidoc/src/06_runtime_view.adoc b/RU/asciidoc/src/06_runtime_view.adoc
new file mode 100644
index 0000000..5839fff
--- /dev/null
+++ b/RU/asciidoc/src/06_runtime_view.adoc
@@ -0,0 +1,48 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-runtime-view]]
+== Представление времени выполнения
+
+[role="arc42help"]
+****
+.Содержание
+Представление времени выполнения описывает конкретное поведение и взаимодействие строительных блоков системы в виде сценариев из следующих областей:
+
+* важные варианты использования или функции: как строительные блоки их выполняют?
+* взаимодействия на критических внешних интерфейсах: как строительные блоки взаимодействуют с пользователями и соседними системами?
+* эксплуатация и администрирование: запуск, запуск, остановка
+* сценарии ошибок и исключений
+
+Примечание: Основным критерием выбора возможных сценариев (последовательностей, рабочих процессов) является их *архитектурная релевантность*.
+*Не* нужно без надобности описывать большое количество сценариев.
+Вам лучше задокументировать репрезентативный выбор.
+
+.Мотивация
+Вы должны понимать, как (экземпляры) строительных блоков вашей системы выполняют свою работу и взаимодействуют во время выполнения.
+В основном вы будете фиксировать сценарии в своей документации, чтобы сообщить о своей архитектуре заинтересованным сторонам, которые менее склонны или не способны читать и понимать статические модели (представление стандартных блоков, представление развертывания).
+
+.Форма
+Существует множество обозначений для описания сценариев, например.
+
+* пронумерованный список шагов (на естественном языке)
+* диаграммы деятельности (activity diagrams) или блок-схемы
+* диаграммы последовательности (sequence diagrams)
+* BPMN или EPC (цепочки обработки событий)
+* конечные автоматы
+* ...
+
+.Дальнейшая информация
+Смотри https://docs.arc42.org/section-6/[Представление времени выполнения] в документации arc42.
+
+****
+
+=== <Сценарий времени выполнения 1>
+
+* _<вставьте диаграмму выполнения или текстовое описание сценария>_
+* _<вставьте описание важных аспектов взаимодействия между экземплярами стандартных блоков, изображенных на этой диаграмме.>_
+
+=== <Сценарий времени выполнения 2>
+
+=== ...
+
+=== <Сценарий времени выполнения n>
diff --git a/RU/asciidoc/src/07_deployment_view.adoc b/RU/asciidoc/src/07_deployment_view.adoc
new file mode 100644
index 0000000..5310c5e
--- /dev/null
+++ b/RU/asciidoc/src/07_deployment_view.adoc
@@ -0,0 +1,89 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-deployment-view]]
+== Представления развертывания
+
+[role="arc42help"]
+****
+Представление развертывания описывает:
+
+1. техническую инфраструктуру, используемую для работы вашей системы, с элементами инфраструктуры, такими как географические местоположения, среды, компьютеры, процессоры, каналы и сетевые топологии, а также другие элементы инфраструктуры и
+
+2. сопоставление строительных блоков (программного обеспечения) с этими элементами инфраструктуры.
+
+Часто системы выполняются в разных средах, например. среда разработки, тестовая среда, продакшн.
+В таких случаях вы должны задокументировать все соответствующие среды.
+
+Особенно важно задокументировать представление развертывания, если ваше программное обеспечение выполняется в виде распределенной системы с более чем одним компьютером, процессором, сервером или контейнером; или когда вы проектируете и создаете свои собственные аппаратные процессоры и микросхемы.
+
+С точки зрения программного обеспечения достаточно зафиксировать только те элементы инфраструктуры, которые необходимы для демонстрации развертывания ваших строительных блоков.
+Архитекторы аппаратного обеспечения могут пойти дальше и описать инфраструктуру с любым уровнем детализации, который им необходим.
+
+.Мотивация
+Программное обеспечение не работает без аппаратного обеспечения.
+Эта базовая инфраструктура может и будет влиять на систему и/или некоторые сквозные (сквозные) концепции.
+Поэтому необходимо знать инфраструктуру.
+
+.Форма
+Возможно, схема развертывания самого высокого уровня уже содержится в разделе 3.2. в виде технического контекста с собственной инфраструктурой, описанного ОДНИМ черным ящиком.
+В этом разделе можно раскрыть этот черный ящик, используя дополнительные диаграммы развертывания:
+
+* UML предлагает диаграммы развертывания, чтобы выразить это представление.
+Используйте его, возможно, с вложенными диаграммами, в случае если ваша инфраструктура более сложна.
+* Если заинтересованные стороны (связанные с аппаратным обеспечением) предпочитают другие виды диаграмм, а не диаграмму развертывания, позвольте им использовать любой вид, способный отображать узлы и каналы инфраструктуры.
+
+.Дальнейшая информация
+Смотри https://docs.arc42.org/section-7/[Представление развертывания] в документации arc42.
+
+****
+
+=== Инфраструктурный уровень 1
+
+[role="arc42help"]
+****
+
+Опишите (обычно в комбинации диаграмм, таблиц и текста):
+
+* распределение системы по нескольким местоположениям, средам, компьютерам, процессорам и т. д., а также физическим соединениям между ними
+* важные обоснования или мотивы для этой структуры развертывания
+* характеристики качества и/или производительности этой инфраструктуры
+* сопоставление программных артефактов с элементами этой инфраструктуры
+
+Для нескольких сред или альтернативных развертываний скопируйте и адаптируйте этот раздел arc42 для всех соответствующих сред.
+****
+
+_**<Обзорная диаграмма>**_
+
+Мотивация::
+
+_<объяснение в текстовом виде>_
+
+Характеристики качества и/или производительности::
+
+_<объяснение в текстовом виде>_
+
+Сопоставление строительных блоков с инфраструктурой::
+_<описание сопоставления>_
+
+=== Инфраструктурный уровень 2
+
+[role="arc42help"]
+****
+Сюда можно включить внутреннюю структуру (некоторых) Инфраструктурных элементов уровня 1.
+
+Пожалуйста, скопируйте структуру уровня 1 для каждого выбранного элемента.
+****
+
+==== _<Инфраструктурный элемент 1>_
+
+_<диаграмма + объяснение>_
+
+==== _<Инфраструктурный элемент 2>_
+
+_<диаграмма + объяснение>_
+
+...
+
+==== _<Инфраструктурный элемент n>_
+
+_<диаграмма + объяснение>_
diff --git a/RU/asciidoc/src/08_concepts.adoc b/RU/asciidoc/src/08_concepts.adoc
new file mode 100644
index 0000000..4e17581
--- /dev/null
+++ b/RU/asciidoc/src/08_concepts.adoc
@@ -0,0 +1,72 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-concepts]]
+== Сквозные концепции
+
+
+[role="arc42help"]
+****
+.Содержание
+В этом разделе описываются главные правила и идеи решений, которые применимы к нескольким частям (= сквозные) вашей системы.
+Такие концепции часто связаны с несколькими строительными блоками.
+Они могут включать множество различных тем, таких как
+
+* модели, особенно модели предметной области
+* архитектура или шаблоны дизайна
+* правила использования конкретных технологий
+* принципиальные, часто технические решения всеобъемлющего (= сквозного) характера
+* правила реализации
+
+
+.Мотивация
+
+Концепции составляют основу _концептуальной целостности_ (непротиворечивости, однородности) архитектуры.
+Таким образом, они являются важным вкладом в достижение внутренних качеств вашей системы.
+
+Некоторые из этих концепций не могут быть отнесены к отдельным строительным блокам, например к безопасности или производительности.
+
+.Форма
+Форма может быть разнообразной:
+
+* концептуальные документы любой структуры
+* сквозные фрагменты моделей или сценарии с использованием обозначений архитектурных представлений
+* примеры реализации, особенно для технических концепций
+* ссылка на типичное использование стандартных фреймворков (например, использование Hibernate для объектно-реляционного сопоставления)
+
+.Структура
+Потенциальная (но не обязательная) структура этого раздела может быть следующей:
+
+* Концепции домена
+* Концепции взаимодействия с пользователем (UX)
+* Концепции безопасности и защиты
+* Архитектура и шаблоны проектирования
+* "Под капотом"
+* концепции развития
+* операционные концепции
+
+Примечание: может быть сложно отнести отдельные концепции к одной конкретной теме в этом списке.
+
+image::08-Crosscutting-Concepts-Structure-EN.png["Возможные темы для сквозных концепций"]
+
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-8/[Концепции] в документации arc42.
+****
+
+
+=== _<Концепция 1>_
+
+_<объяснение>_
+
+
+
+=== _<Концепция 2>_
+
+_<объяснение>_
+
+...
+
+=== _<Концепция n>_
+
+_<объяснение>_
diff --git a/RU/asciidoc/src/09_architecture_decisions.adoc b/RU/asciidoc/src/09_architecture_decisions.adoc
new file mode 100644
index 0000000..6786d1d
--- /dev/null
+++ b/RU/asciidoc/src/09_architecture_decisions.adoc
@@ -0,0 +1,33 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-design-decisions]]
+== Архитектурные решения
+
+
+[role="arc42help"]
+****
+.Содержание
+Важные, дорогие, крупномасштабные или рискованные архитектурные решения, включая их обоснование.
+Под «решениями» мы подразумеваем выбор одной альтернативы на основе заданных критериев.
+
+Решите сами, следует ли документировать архитектурное решение в этом центральном разделе, или лучше документировать это локально (например, в шаблоне белого ящика одного стандартного блока).
+
+Избегайте избыточности.
+Обратитесь к разделу 4, где вы уже зафиксировали наиболее важные решения вашей архитектуры.
+
+.Мотивация
+Заинтересованные лица вашей системы должны иметь возможность понять и проследить ваши решения.
+
+.Форма
+Различные варианты:
+
+* ADR (https://cognitect.com/blog/2011/11/15/documenting-architecture-decisions[Документирование архитектурных решений]) для каждого важного решения
+* Список или таблица, упорядоченные по важности и последствиям или:
+* подробнее в виде отдельных разделов по решению
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-9/[Архитектурные решения] в документации arc42.
+Там вы найдете ссылки и примеры по ADR.
+
+****
diff --git a/RU/asciidoc/src/10_quality_requirements.adoc b/RU/asciidoc/src/10_quality_requirements.adoc
new file mode 100644
index 0000000..81a6c0d
--- /dev/null
+++ b/RU/asciidoc/src/10_quality_requirements.adoc
@@ -0,0 +1,70 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-quality-scenarios]]
+== Требования к качеству
+
+
+[role="arc42help"]
+****
+
+.Содержание
+Этот раздел содержит все требования к качеству в виде дерева качества со сценариями. Наиболее важные из них уже были описаны в разделе 1.2. (цели качества)
+
+Здесь вы также можете зафиксировать требования к качеству с меньшим приоритетом,
+не создающие высоких рисков будучи не полностью достигнутыми.
+
+.Мотивация
+Поскольку требования к качеству будут иметь большое влияние на архитектурные
+решения, вы должны знать что действительно важно для каждой из заинтересованных сторон (конкретно и измеримо).
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-10/[Требования к качеству] в документации arc42.
+
+****
+
+=== Дерево качества
+
+[role="arc42help"]
+****
+.Содержание
+Дерево качества (как определено в ATAM — Architecture Tradeoff Analysis Method) со сценариями качества/оценки в виде листьев.
+
+.Мотивация
+Древовидная структура с приоритетами обеспечивает обзор большого количества требований к качеству.
+
+.Форма
+Дерево качества представляет собой высокоуровневый обзор целей и требований в области качества:
+
+* древовидное уточнение термина «качество». Используйте «качество» или «полезность» в качестве корня
+* майндмпеп с категориями качества в качестве основных ветвей
+
+В любом случае дерево должно включать ссылки на сценарии следующего раздела.
+
+****
+
+=== Сценарии качества
+
+[role="arc42help"]
+****
+.Содержание
+Конкретизация (иногда расплывчатых или неявных) требований к качеству с использованием сценариев (качества).
+
+Эти сценарии описывают, что должно произойти, когда в систему поступает стимул.
+
+Для архитекторов важны два вида сценариев:
+
+* Сценарии использования (также называемые сценариями приложений или сценариями вариантов использования) описывают реакцию системы во время выполнения на определенный стимул. Сюда также входят сценарии, описывающие эффективность или производительность системы. Пример: Система реагирует на запрос пользователя в течение одной секунды.
+* Сценарии изменений описывают модификацию системы или ее ближайшего окружения. Пример: Реализована дополнительная функциональность или изменены требования к атрибуту качества.
+
+.Мотивация
+Сценарии конкретизируют требования к качеству и позволяют
+легче измерить или решить, выполнены ли они.
+
+Особенно, когда вы хотите оценить свою архитектуру, используя такие методы, как
+ATAM вам необходимо описать ваши цели в области качества (из раздела 1.2)
+точнее до уровня сценариев, которые можно обсуждать и оценивать.
+
+.Форма
+Табличный или произвольный текст.
+****
diff --git a/RU/asciidoc/src/11_technical_risks.adoc b/RU/asciidoc/src/11_technical_risks.adoc
new file mode 100644
index 0000000..e2a4cef
--- /dev/null
+++ b/RU/asciidoc/src/11_technical_risks.adoc
@@ -0,0 +1,25 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-technical-risks]]
+== Риски и технический долг
+
+
+[role="arc42help"]
+****
+.Содержание
+Список выявленных технических рисков или технических долгов, упорядоченный по приоритету
+
+.Мотивация
+«Управление рисками — это управление проектами для взрослых» (Тим Листер, Atlantic Systems Guild).
+
+Это должно быть вашим девизом для систематического обнаружения и оценки рисков и технических задолженностей в архитектуре, которые потребуются управляющим заинтересованным сторонам (например, руководителям проектов, владельцам продуктов) в рамках общего анализа рисков и планирования измерений.
+
+.Форма
+Список рисков и/или технических долгов, возможно, включая предлагаемые меры по минимизации, смягчению или предотвращению рисков или сокращению технических долгов.
+
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-11/[Риски и технический долг] в документации arc42.
+
+****
diff --git a/RU/asciidoc/src/12_glossary.adoc b/RU/asciidoc/src/12_glossary.adoc
new file mode 100644
index 0000000..8eb47d4
--- /dev/null
+++ b/RU/asciidoc/src/12_glossary.adoc
@@ -0,0 +1,41 @@
+ifndef::imagesdir[:imagesdir: ../images]
+
+[[section-glossary]]
+== Глоссарий
+
+[role="arc42help"]
+****
+.Содержание
+Наиболее важные доменные и технические термины, которые ваши заинтересованные стороны используют при обсуждении системы.
+
+Вы также можете использовать глоссарий в качестве источника переводов, если вы работаете в многоязычной команде.
+
+.Мотивация
+Вы должны четко определить свои условия, чтобы все заинтересованные стороны
+
+* имели одинаковое понимание этих терминов
+* не использовали синонимы и омонимы
+
+.Форма
+
+Таблица со столбцами <Термин> и <Определение>.
+
+Потенциально больше столбцов на случай, если вам понадобятся переводы.
+
+
+.Дальнейшая информация
+
+Смотри https://docs.arc42.org/section-12/[Глоссарий] в документации arc42.
+
+****
+
+[cols="e,2e" options="header"]
+|===
+|Термин |Определение
+
+|<Термин-1>
+|<определение-1>
+
+|<Термин-2>
+|<определение-2>
+|===
diff --git a/RU/asciidoc/src/about-arc42.adoc b/RU/asciidoc/src/about-arc42.adoc
new file mode 100644
index 0000000..0381f76
--- /dev/null
+++ b/RU/asciidoc/src/about-arc42.adoc
@@ -0,0 +1,15 @@
+:homepage: https://arc42.org
+
+:keywords: software-architecture, documentation, template, arc42
+
+:numbered!:
+**Об arc42**
+
+[role="lead"]
+arc42, шаблон для документации программного обеспечения и системной архитектуры.
+
+Версия шаблона {revnumber}. {revremark}, {revdate}
+
+Создано и поддерживается (C) доктором Петером Хрушкой, доктором Гернотом Старке и другими участниками.
+Смотри https://arc42.org.
+
diff --git a/RU/asciidoc/src/config.adoc b/RU/asciidoc/src/config.adoc
new file mode 100644
index 0000000..369d72b
--- /dev/null
+++ b/RU/asciidoc/src/config.adoc
@@ -0,0 +1,9 @@
+// asciidoc settings for RU (Russian)
+// ==================================
+:toc-title: table of contents
+
+// enable table-of-contents
+:toc:
+
+// where are images located?
+:imagesdir: ./images