= определение
. действие
! риск
→ вывод
@ метаданные
? вопрос
* контекст
~ напряжение
| ресурс
⟶
Часть I — Что такое язык предметной области
01 · Определение
=язык предметной области (Domain-Specific Language, DSL) — структурированный набор терминов и правил, одинаково понятный бизнес-пользователям и разработчикам в конкретной предметной области
=цель: устранить разрыв между тем, как бизнес описывает процессы, и тем, как они реализуются в коде, интерфейсе и документации
~синонимы и смежные понятия: Ubiquitous Language · отраслевой глоссарий · деловой словарь · предметный словарь
@термин введён Эриком Эвансом в книге «Domain-Driven Design» (2003); активно применяется в проектировании корпоративных систем, включая 1С
02 · Проблема без DSL
!типичная ситуация: бухгалтер говорит «компенсация за неиспользованный отпуск», в коде это `kompOtpusk`, в интерфейсе 1С — «Вид начисления 48», в ТЗ — «выплата при увольнении»
*итог: разработчик реализует не то, что имел в виду бухгалтер → ошибка в расчёте → нарушение ТК РФ → штраф по ст. 5.27 КоАП РФ
*итог: тестировщик не может проверить правило, потому что не понимает бизнес-логику
*итог: смена разработчика = полная переработка, потому что нигде нет единого словаря
→DSL фиксирует: «компенсация за неиспользованный отпуск» — это всегда именно так, во всех артефактах
⟶
Часть II — Виды DSL
03 · Классификация
=внешний DSL (External DSL) — отдельный язык с собственным синтаксисом и парсером
.примеры: SQL (язык для баз данных) · регулярные выражения · язык запросов 1С
~плюс: максимально близок к естественному языку предметной области
~минус: требует разработки парсера и среды выполнения
=внутренний DSL (Internal DSL) — надстройка над языком программирования, использующая его синтаксис
.примеры: Fluent Interface в Java/C# · цепочки методов · конфигурационные файлы YAML/JSON
~плюс: не нужен отдельный парсер — используется основной язык
~минус: ограничен синтаксисом хост-языка
=предметный глоссарий (Glossary DSL) — не язык программирования, а документ: таблица терминов
.наиболее практичный вид для большинства бизнес-проектов, в т.ч. на 1С
.формат: термин | определение | источник (закон/стандарт) | как реализован в системе
+доступен всем участникам: бухгалтеру, разработчику, аналитику, аудитору
⟶
Часть III — DDD и Ubiquitous Language
04 · Domain-Driven Design — основы
=Domain-Driven Design (DDD) — подход к проектированию ПО, при котором модель строится вокруг предметной области (бизнеса), а не вокруг технических решений
@автор: Эрик Эванс · книга «Domain-Driven Design» (2003) · продолжение: Вон Вернон «Implementing Domain-Driven Design» (2013)
.ключевые концепции DDD: Ubiquitous Language · Bounded Context · Aggregate · Entity · Value Object · Domain Event
~DDD особенно эффективен в сложных доменах: бухгалтерия, налоги, кадровый учёт, банки, страхование
05 · Ubiquitous Language — единый язык
=Ubiquitous Language (единый язык) — практика DDD: все участники команды используют одни и те же термины везде — в разговорах, документах, коде, тестах и интерфейсе
~«ubiquitous» — вездесущий, повсеместный: язык должен быть одним на всех, не только в коде
=DSL — это формализованная реализация Ubiquitous Language в виде глоссария и правил именования
.разница: Ubiquitous Language — принцип, DSL — конкретный инструмент его реализации
КОНЦЕПЦИЯЧТО ЭТОСВЯЗЬ
DDDМетодология проектирования ПО от доменаМетодология — содержит UL и DSL
Ubiquitous LanguageПринцип единого языка для всехПрактика DDD — реализуется через DSL
DSLФормализованный набор терминов и правилИнструмент реализации Ubiquitous Language
ГлоссарийДокумент с определениями терминовАртефакт DSL — его физическое воплощение
⟶
Часть IV — Как создать DSL
06 · Этапы создания
.шаг 1: определить предметную область — бухгалтерия, кадры, склад, CRM (каждая — свой DSL)
.шаг 2: провести Event Storming или интервью с экспертами домена — выписать все термины, которые они используют
.шаг 3: привязать каждый термин к источнику — закон, ГОСТ, внутренний регламент
*пример: «Ежегодный основной оплачиваемый отпуск» → ст. 115 ТК РФ
.шаг 4: описать, как термин реализован в системе — имя объекта в 1С, поле в БД, API-параметр
.шаг 5: зафиксировать в глоссарии (Excel, Confluence, wiki) — доступном всей команде
.шаг 6: внедрить в процесс: проверять код-ревью на соответствие DSL, обновлять глоссарий при изменении законодательства
07 · Структура глоссария
ТЕРМИНОПРЕДЕЛЕНИЕИСТОЧНИКВ 1С
Ежегодный отпускОсновной оплачиваемый отпуск 28 к. дн.ст. 115 ТК РФВид начисления «Отпуск»
АвансВыплата зарплаты за первую половину месяцаст. 136 ТК РФДокумент «Аванс»
Сверхурочная работаРабота сверх нормы рабочего времени по приказуст. 99 ТК РФВид начисления «Сверхурочные»
Материальная выгодаВыгода от экономии на процентах по займуст. 212 НК РФВид дохода НДФЛ «Матвыгода»
⟶
Часть V — DSL в 1С:Бухгалтерия
08 · Как применять DSL в 1С
=DSL в 1С реализуется через именование объектов метаданных, элементов справочников и реквизитов форм
.справочники: наименования элементов должны точно совпадать с терминами из законодательства и DSL-глоссария
.перечисления: значения («Действующий», «Расторгнут») — из формулировок ТК РФ, не внутренний сленг
.формы: надписи кнопок, полей, вкладок — из единого глоссария
.комментарии в коде: использовать бизнес-термины, а не технические аббревиатуры
!главное правило: если бизнес-пользователь не понимает надпись в интерфейсе — это нарушение DSL
09 · Пример: именование в коде
-плохо (без DSL): переменная `kompOtpusk`, параметр `IDVid48`, комментарий «// выплата при уходе»
*программист понимает, бухгалтер — нет. При смене разработчика — контекст теряется полностью
+хорошо (с DSL): переменная `КомпенсацияЗаНеиспользованныйОтпуск`, параметр `ВидНачисления.КомпенсацияОтпуска`, комментарий «// ст. 127 ТК РФ»
+бухгалтер сможет прочитать и проверить бизнес-логику без помощи разработчика
+аудитор сразу видит соответствие норме закона
⟶
Часть VI — С DSL и без DSL
10 · Сравнение подходов
КРИТЕРИЙБЕЗ DSLС DSL
Понимание кода бухгалтеромНевозможно — сленг и аббревиатурыДоступно — термины из ТК и НК РФ
Риск ошибки в расчётахВысокий — термины трактуются по-разномуНизкий — однозначное толкование
Скорость онбордингаДолго — нужно изучать внутренний сленгБыстро — термины совпадают с реальностью
Соответствие проверкамСложно доказать при несоответствии терминовВысокое — система «говорит» на языке закона
Поддержка после смены командыТребует переработки — контекст утерянСтандартная — глоссарий сохраняет контекст
Юридические рискиВысокие — ошибки из-за терминологической путаницыМинимальные — термины из актуального законодательства
⟶
Часть VII — Чеклисты
11 · Чеклист: создать DSL
.☐ Определить границы предметной области (Bounded Context)
.☐ Провести интервью с экспертами домена — выписать все используемые термины
.☐ Привязать каждый термин к источнику (закон, ГОСТ, регламент)
.☐ Описать, как термин реализован в системе (имя объекта, поле, API)
.☐ Создать глоссарий в доступном месте (Confluence, Excel, wiki)
.☐ Обсудить глоссарий с командой — убедиться, что все согласны с определениями
.☐ Назначить ответственного за актуализацию глоссария
12 · Чеклист: аудит текущей системы на DSL
.☐ Сравнить наименования объектов в 1С с терминами в законодательстве — совпадают?
.☐ Попросить бухгалтера прочитать имена переменных в коде — он понимает?
.☐ Проверить ТЗ: используются ли в нём те же термины, что в коде и интерфейсе?
.☐ Найти синонимы одного понятия в разных документах — унифицировать
.☐ Проверить комментарии в коде — содержат ли ссылки на статьи закона?
⟶
Часть VIII — Топ-6 ошибок
!Ошибка 1: создать DSL только для кода, забыв про интерфейс и документацию
*если в коде «КомпенсацияОтпуска», а в интерфейсе кнопка «Расчёт при увольнении» — это разные миры
→DSL должен быть во всех артефактах: ТЗ · код · тесты · интерфейс · справка · документация
!Ошибка 2: включить в глоссарий внутренний сленг и жаргон
*«ЗУПник», «авансик», «закрыть квартал» — понятны внутри, но нечёткие и необязывающие
→только официальные термины из законодательства, ГОСТ и утверждённых регламентов
!Ошибка 3: не обновлять DSL при изменении законодательства
*закон изменился — термин изменился — в системе он старый — ошибка в расчётах
→назначить ответственного; подписаться на мониторинг изменений (КонсультантПлюс, ИТС 1С)
!Ошибка 4: создать один общий DSL для всех доменов
*«Контрагент» в бухгалтерии и «Контрагент» в CRM — разные объекты с разными правилами
→разграничить Bounded Context: отдельный DSL для бухгалтерии, кадров, склада, CRM
!Ошибка 5: сделать глоссарий, но не рассказать команде
*глоссарий лежит в Confluence, но никто о нём не знает — он бесполезен
→провести воркшоп · добавить проверку DSL в процесс код-ревью · упомянуть в онбординге
!Ошибка 6: ограничиться определениями без примеров реализации
*«Компенсация отпуска — выплата при увольнении» — понятно, но разработчик всё равно не знает, как это назвать в коде
→в глоссарии добавить колонку «Как реализовано в системе»: имя объекта 1С · поле · метод
