style: убрать излишний англицызм

DRAFT/level-3/terminology.md

@@ -2,84 +2,86 @@
 
 > Нормативные определения рабочего черновика. Этот раздел не объявляет правила.
 
-Level 3 наследует терминологию Levels 1-2 и заменяет структурную модель доменного модуля Level 2 новой сущностью Domain.
+Level 3 наследует терминологию Level 1 и Level 2 и заменяет доменный модуль Level 2 новой структурной сущностью — доменом Level 3.
 
-## Domain
+## Домен Level 3
 
-### Domain
+### Домен
 
-Немодульная предметная граница слоя `domains`, представляющая одну самостоятельную предметную область. Domain объединяет role modules и Groups этой области, но не содержит собственного runtime-кода, состояния, lifecycle, public API или узла графа зависимостей.
+Немодульная предметная граница слоя `domains`, представляющая одну самостоятельную предметную область. Домен объединяет модули и группы этой области, но не имеет собственного исполняемого кода, состояния, жизненного цикла, публичного API или узла графа зависимостей.
 
-Domain не является module и не является Group. Он может находиться непосредственно в слое `domains` или внутри навигационной Group этого слоя. В этом частном случае Group вправе содержать Domain, но сохраняет все остальные свойства Group Level 1.
+Домен не является ни модулем, ни группой. Он может находиться непосредственно в слое `domains` или внутри навигационной группы этого слоя. Такая группа вправе содержать домены, но сохраняет остальные свойства группы Level 1.
 
-Module, расположенный непосредственно внутри Domain или внутри его Group, не является вложенным module: ближайшая внешняя граница Domain не является module.
+Модуль, расположенный непосредственно внутри домена или одной из его групп, не считается вложенным: его ближайшая внешняя граница не является модулем.
 
-### Role module
+### Модуль домена
 
-Module внутри Domain, чья ответственность определяется одной технической ролью: `business`, preset, adapter или framework binding. Каждый role module остаётся обычным module Level 1 со своим public API и узлом графа зависимостей.
+Модуль внутри домена, ответственность которого соответствует одной технической роли: бизнес-логике, типовой сборке, адаптеру или связи с фреймворком. Каждый модуль домена остаётся обычным модулем Level 1 со своим публичным API и узлом графа зависимостей.
 
-### Business module
+### Модуль бизнес-логики
 
-Обязательный module `business` внутри Domain. Он определяет public business scenarios, business contracts, factory, ports, domain errors, детерминированные правила и семантику domain state.
+Обязательный модуль `business` внутри домена. Он определяет публичные предметные сценарии и контракты, фабрику, порты, ошибки предметной области, детерминированные правила и модель состояния.
 
-`business` не зависит от concrete runtime, execution environment или framework.
+Модуль `business` не зависит от конкретной среды выполнения, технической реализации или фреймворка.
 
-### Port
+### Порт
 
-Минимальный business-owned contract runtime capability, которая нужна business для выполнения scenario. Port описывается языком предметной области и не раскрывает SDK, generated DTO, store, hook, platform object или другой concrete runtime.
+Минимальный контракт возможности, которая нужна бизнес-логике для выполнения предметного сценария. Порт принадлежит модулю `business`, использует язык предметной области и не раскрывает SDK, сгенерированные DTO, хранилище, хук, объект платформы или другую техническую реализацию.
 
-### Factory
+### Фабрика
 
-Функция business module, которая получает полный набор ports и создаёт business API instance. Factory не является assembly и не выбирает concrete implementation ports.
+Функция модуля `business`, которая получает полный набор портов и создаёт экземпляр публичного API бизнес-логики. Фабрика не выбирает реализации портов и не является готовой сборкой для конкретной среды.
 
-### Adapter
+### Адаптер
 
-Код, который реализует один или несколько business ports поверх concrete runtime: SDK, storage, platform API, request input, state manager или технического сервиса. Adapter может быть private segment preset module либо самостоятельным promoted adapter module.
+Код, который реализует один или несколько портов поверх конкретного SDK, хранилища, API платформы, данных запроса, системы управления состоянием или технического сервиса. Адаптер может быть закрытым сегментом модуля сборки либо самостоятельным модулем в группе `adapters`.
 
-### Preset
+### Типовая сборка
 
-Module с именованной повторяемой assembly одной business factory для execution context. Preset выбирает implementations ports и сообщает caller, как владеть созданным API instance.
+Модуль в группе `presets`, который повторяемо создаёт API одной фабрики для именованного контекста выполнения. Он выбирает реализации портов и возвращает вызывающему коду операции, необходимые для управления жизненным циклом созданного экземпляра.
 
-### Framework module
+### Модуль фреймворка
 
-Role module, который существует из-за contract конкретного framework. Такой module размещается непосредственно в Domain и называется именем framework: `react`, `vue` и аналогично. Он получает готовый business API, но не собирает factory и не реализует concrete adapter.
+Модуль домена, который связывает публичный API бизнес-логики с конкретным фреймворком. Он размещается непосредственно в домене и называется именем фреймворка: `react`, `vue` и аналогично. Такой модуль получает готовый API, но не вызывает фабрику и не реализует технические адаптеры.
 
-### Assembly site
+### Место сборки
 
-Место, которое вызывает business factory, передаёт полный набор ports и получает API instance. Reusable assembly оформляется preset module; одноразовая assembly принадлежит явному composition graph owner. Framework module не является assembly site.
+Место, которое вызывает фабрику, передаёт полный набор портов и получает экземпляр API. Повторяемое место сборки оформляется модулем в группе `presets`; одноразовая сборка принадлежит явному владельцу графа. Модуль фреймворка не является местом сборки.
 
-### Graph owner
+### Владелец графа
 
-Код, который удерживает конкретный runtime graph и API instances в execution scope и вызывает предоставленные start/cleanup operations. Graph owner не заменяет module-владельца lifecycle resource; contract создания, области жизни, числа instances и cleanup определяет module по правилам Level 1. Graph owner может быть application, route, page, request или test scope.
+Код модуля, который удерживает собранный граф и его экземпляры API в пределах объявленной области жизни, а также вызывает предоставленные операции запуска и очистки. Владелец графа не заменяет владельца ресурса: контракт жизненного цикла определяет модуль, которому принадлежит ресурс, по правилам Level 1.
 
-### Environment boundary
+Владельцем графа может быть модуль приложения, маршрута, страницы, запроса или теста.
 
-Граница между client-only, server-only и isomorphic import graphs. Она определяется достижимостью import graph, а не названием папки или надеждой на tree shaking.
+### Граница среды выполнения
+
+Граница между графами импортов, предназначенными только для клиента, только для сервера или для обеих сред. Она определяется достижимостью импортов, а не названием папки или удалением неиспользуемого кода при сборке.
 
 ## Виды владения
 
-Level 3 различает три вопроса, которые в обычной речи могут называться владением:
+Level 3 разделяет три разных вопроса:
 
 | Вопрос | Ответственный |
 |---|---|
-| Какая предметная область и словарь объединяют код | Domain |
-| Кто владеет самостоятельной ответственностью и public API | Конкретный module |
-| Кто удерживает API instance в execution scope и вызывает lifecycle operations | Graph owner |
+| Какая предметная область и словарь объединяют код | Домен |
+| Кто владеет самостоятельной ответственностью и публичным API | Конкретный модуль |
+| Кто удерживает экземпляры API и завершает их жизненный цикл | Владелец графа |
 
-Например, `business` владеет моделью `AuthState` и её допустимыми переходами. Adapter владеет concrete state runtime и его lifecycle contract. Graph owner удерживает конкретный `AuthApi` instance в допустимом scope и вызывает его cleanup.
+Например, модуль `business` владеет моделью `AuthState` и допустимыми переходами между её состояниями. Модуль, содержащий адаптер, владеет конкретным механизмом хранения и определяет контракт его жизненного цикла. Владелец графа удерживает созданный `AuthApi` в допустимой области жизни и вызывает очистку.
 
 ## Структурная модель
 
 ```text
-SLM root
+корень SLM
 └── domains
-    └── Domain
-        ├── business module
-        ├── presets Group
-        │   └── preset module
-        ├── adapters Group
-        │   └── adapter module
-        └── react framework module
+    └── домен
+        ├── модуль business
+        ├── группа presets
+        │   └── модуль типовой сборки
+        ├── группа adapters
+        │   └── модуль адаптера
+        └── модуль react
 ```
 
-`presets` и `adapters` являются Groups только при наличии соответствующих modules. `errors`, `ports`, `services`, `types`, `hooks` и `providers` являются segments своих module-владельцев, если сами не образуют отдельный module.
+Группы `presets` и `adapters` существуют только при наличии соответствующих модулей. Каталоги `errors`, `ports`, `services`, `types`, `hooks` и `providers` являются сегментами своих модулей-владельцев, если сами не образуют самостоятельный модуль.