Опираясь на 01.01 Понятие системы и системного подхода, 01.02 Ментальные модели аналитика и 01.03 Техники анализа проблем, а также на бережливый подход из 01.05 Теория ограничений и бережливое мышление, аналитик переходит к инженерным правилам, на которых строятся устойчивые границы решения и качество формулировок. Эта заметка — не про код: здесь проверочные вопросы к scope, декомпозиции, интеграции и процессам. Детали архитектуры, DDD, API и BPMN — в соседних разделах; здесь — карта принципов и семейств паттернов, чтобы не плодить хрупкие требования.

1. Суть темы

Принципы проектирования — устойчивые правила выбора: что включать в scope, как резать систему на части, где фиксировать знание один раз. Паттерны проектирования — типовые решения повторяющихся задач на уровне анализа: распределение обязанностей (GRASP), границы предметной области (идеи DDD), взаимодействие систем (EIP), фрагменты процессов (BPMN).

GoF-паттерны на уровне классов сознательно опущены: на этапе анализа важнее семейства, которые напрямую отражаются в user stories, use cases, интеграционных сценариях и моделях процессов. Четыре уровня паттернов в статье не смешиваются случайно:

УровеньСемействоВопрос аналитика
Распределение обязанностейGRASPКто в спецификации отвечает за расчёт, создание, обработку события?
Предметная областьИдеи DDDГде заканчивается смысл термина и единица изменения данных?
ИнтеграцияEIPКак системы обмениваются данными при заданных SLA и согласованности?
ПроцессProcess patternsКак выглядит жизненный цикл объекта и типовые ветвления в BPMN?

Принцип фиксируется в требовании, когда он задаёт поведение или ограничение для заказчика и команды; в архитектурном решении (ADR) — когда это выбор между альтернативами реализации с долгосрочными последствиями (см. 10.01.13 Шаблон архитектурного решения (ADR)). Граница БТ / ФТ / НФТ — 02.03.01 Классификация требований (БТ, ФТ, НФТ); НФТ вроде modifiability и interoperability часто становятся формальной «оболочкой» принципов — см. 08.02 Нефункциональные требования (НФТ) — классификация и стандарты.

2. Ключевые понятия

2.1. Фундаментальные принципы

KISS (Keep It Simple, Stupid) — решение не сложнее задачи. В спецификации: не плодить сущности «на всякий случай», предпочитать линейный процесс, если ветвление не даёт ощутимой ценности. Антипаттерн: спецификация на сотни страниц с редкими исключениями, которые никогда не наступят.

YAGNI (You Ain't Gonna Need It) — не закладывать функциональность, пока нет подтверждённой потребности. Связь с Lean и XP: 01.05 Теория ограничений и бережливое мышление, 05.05 Методология быстрой разработки (RAD, XP). Scope и MVP — 02.01.04 Определение границ решения (Scope Modelling), приоритизация — 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано). Антипаттерн: gold plating и раздел «на будущее» в BRD без привязки к текущей цели.

DRY (Don't Repeat Yourself) — каждая значимая часть знания имеет одно непротиворечивое место в системе документов. Единый глоссарий — 10.01.14 Шаблон глоссария и словаря данных; одно правило — одна формулировка с трассировкой в stories и use cases — 02.03.04 Трассировка требований (концепция). Форматы BRD/SRS/FRD — 04.01 Форматы документов (Vision&Scope, BRD, SRS, FRD). Антипаттерн: одно бизнес-правило скопировано в пять разделов; при изменении расходятся формулировки.

SOLID — пять принципов ООП, адаптированных к артефактам анализа:

  • S — Single Responsibility: модуль, сервис или story отвечает за одну бизнес-способность. User Story — одна ценность (04.02 Пользовательские истории (User Stories) и Job Stories); Use Case — одна цель актора (03.02.01 Диаграмма прецедентов (Use Case Diagram)).
  • O — Open/Closed: система расширяется без ломки ядра — точки расширения (plug-in, настраиваемые справочники) явно в требованиях. Конфликт с KISS: расширяемость vs срок поставки — фиксируйте в ADR, что откладывается до следующего релиза. OCP формулирует что должно расширяться в требованиях и ADR; GRASP Protected Variations подсказывает, куда в декомпозиции повесить абстракцию — это разные вопросы, не дубли одной идеи.
  • L — Liskov Substitution: подтипы заменяют базовый тип без сюрпризов — проверяйте иерархии сущностей («Юрлицо» / «Физлицо» как «Контрагент») через единый сценарий в stories или use case: подтип проходит те же шаги без «особых исключений».
  • I — Interface Segregation: актор видит только релевантные операции — отдельные контракты API, ролевые экраны и разделы BRD по ролям вместо универсальной формы «на всех».
  • D — Dependency Inversion: требования в терминах предметной области и глоссария, не СУБД или фреймворка; бизнес-логика не привязана к технологии в формулировке.

Связность (Cohesion) и сцепление (Coupling) — две стороны декомпозиции: внутри модуля всё про одну задачу (высокая связность), между модулями — минимум зависимостей через стабильные интерфейсы (низкое сцепление). Антипаттерн: «божественный» модуль в спецификации, который одновременно про оплату, доставку и отчётность — признак низкой связности и высокого сцепления.

2.2. GRASP — распределение обязанностей в спецификации

GRASP (General Responsibility Assignment Software Patterns) на этапе анализа — проверочные вопросы к компонентной и сервисной декомпозиции, а не инструкция по классам. Девять паттернов:

ПаттернВопрос аналитикаПример в спецификации
Information ExpertУ кого уже есть данные для расчёта или проверки?Скидку считает модуль «Заказ», а не «Клиент»
CreatorКто логично создаёт экземпляр по связи?Позиции заказа создаёт «Заказ», не «Каталог»
ControllerКто принимает системное событие первым?Роль «приём заявки» для UC «Оформить заявку» — не обязательное имя класса
Low CouplingМожно ли ослабить связь между компонентами?Событие вместо прямого вызова чужой БД
High CohesionВсе обязанности компонента про одну цель?«Платёж» не смешивает сверку и печать чека
PolymorphismГде поведение зависит от типа без цепочки if?Разные правила для типов контрагента через общий контракт
Pure FabricationНужен ли служебный компонент без прямой доменной сущности?«Отчётный агрегатор», «Адаптер внешнего API»
IndirectionНужен ли посредник, чтобы развязать стороны?Очередь или шина между системами A и B
Protected VariationsЧто изолировать от будущих изменений?Абстракция «Провайдер оплаты» вместо одного вендора

Use Case и последовательности — 03.02.01 Диаграмма прецедентов (Use Case Diagram), 03.02.03 Диаграмма последовательности (Sequence Diagram); декомпозиция системы — 03.01.03 Декомпозиция системы на подсистемы и модули.

2.3. Идеи предметной области (граница с DDD)

Для сложной бизнес-логики достаточно трёх опорных идей; полный DDD — в 03.06.02 Основы Domain-Driven Design:

  • Единый язык (Ubiquitous Language) — термины в спецификации совпадают с языком бизнеса, не с таблицами БД.
  • Ограниченный контекст (Bounded Context) — у термина один смысл внутри границы; между контекстами — явный контракт перевода.
  • Агрегат (Aggregate) — единица изменения: транзакционная целостность внутри кластера сущностей.

Конфликт DRY vs bounded context: в разных контекстах допустимы разные модели «Клиента» — DRY не означает одну таблицу на всю корпорацию.

2.4. Интеграционные паттерны (EIP)

Шаблоны из Hohpe & Woolf описывают поведение обмена, не реализацию брокера. Таблица ниже — критерии для формулировки требований; протоколы, контракты и топологии — в 03.05.01 Виды интеграции (точка-точка, ESB, API-led), 03.05.02 Синхронные протоколы (REST, gRPC, GraphQL), 03.05.04 Асинхронное взаимодействие (очереди, Kafka, Events).

СценарийКритерииТиповой шаблонНФТ и критерии приёмки
Разовая выгрузка файловНизкая частота, допустима задержкаFile TransferSLA доставки, формат и кодировка файла
Жёсткая согласованность «здесь и сейчас»Синхронный ответ, малый объёмRequest-ReplyLatency, таймаут, коды ошибок
Слабая связность, пиковые нагрузкиАсинхронность, буферизацияMessaging, Message BrokerГарантия доставки, retry, идемпотентность
Один факт — много подписчиковFan-out без знания получателейPublish-SubscribeПорядок событий, at-least-once vs exactly-once
Маршрутизация по содержимомуРазные системы по типу сообщенияContent-Based RouterПравила маршрутизации в спецификации
Разбиение/сборка пакетаКрупное сообщение или параллельная обработкаSplitter / AggregatorКорреляция частей, таймаут сборки

Выбранный шаблон фиксируйте в НФТ и критериях приёмки интеграции — см. 08.02 Нефункциональные требования (НФТ) — классификация и стандарты, 02.04.02 Критерии приёмки (Acceptance Criteria). Событийная модель — 03.05.06 Event-Driven Architecture; контракты — 03.05.03 Спецификации контрактов (OpenAPI, AsyncAPI, Protobuf).

2.5. Паттерны бизнес-процессов

Типовые фрагменты для BPMN и state-моделей:

2.6. Эволюция без big bang

Паттерны Strangler Fig (постепенная замена legacy новым контуром) и Feature Toggle (включение функциональности без полного релиза) относятся к эволюции архитектуры и поставки, а не к BPMN-фрагментам. Каталог распределённых паттернов — 03.06.01 Архитектурные паттерны распределённых систем; разбор миграции — 10.02 Разбор кейса "Миграция legacy-системы".

3. Как применяется в работе аналитика

KISS, YAGNI и DRY одинаково работают в BRD, user stories и критериях приёмки — UML и sequence-диаграммы не обязательны. SOLID и GRASP переводятся в роли, глоссарий, границы stories и разделы спецификации; диаграммы помогают, но проверочные вопросы остаются текстовыми.

Принцип / паттернЭффект в требованиях и артефактах
KISS, YAGNIУзкий scope, MVP, простые проверяемые критерии приёмки — 02.04.02 Критерии приёмки (Acceptance Criteria)
DRYСогласованность BRD/SRS, единый глоссарий, трассировка без копипасты
Single ResponsibilityАтомарные stories, чёткие границы use cases, независимая приоритизация
Open/Closed vs KISSЯвное решение в ADR: что расширяем сейчас, что откладываем
Cohesion / CouplingДекомпозиция на модули и сервисы, меньше интеграционных узлов — 03.01.03 Декомпозиция системы на подсистемы и модули
GRASPКто считает, кто создаёт, кто принимает событие — видно на диаграммах и в тексте UC
Идеи DDDОдин язык с бизнесом, границы контекста, единица изменения
EIPТребования к доставке, форматам, ошибкам интеграции, не только «система B получит данные»
Process patternsПовторяемые фрагменты в BPMN без изобретения с нуля
Strangler / ToggleПоэтапная миграция и управляемый rollout в ADR и roadmap

Классификация того, что идёт в требование, а что в ADR — 02.03.01 Классификация требований (БТ, ФТ, НФТ). В Agile принципы не противоречат «just enough documentation» (05.02 Scrum и Kanban (аналитик в Agile)): KISS и YAGNI как раз сокращают объём, DRY — дубли в Confluence и Jira.

graph TD
    subgraph "Принципы"
        KISS["KISS"] --> QUAL["Качество формулировок"]
        YAGNI["YAGNI"] --> QUAL
        DRY["DRY"] --> QUAL
        SOLID["SOLID"] --> QUAL
        COHESION["Связность / сцепление"] --> QUAL
        COHESION --> DECOMP["Декомпозиция модулей"]
    end

    subgraph "Паттерны"
        GRASP["GRASP"] --> BEHAV["Поведение компонентов"]
        DOMAIN["Идеи DDD"] --> BEHAV
        INTEGRATION["EIP"] --> BEHAV
        PROCESS["Process patterns"] --> BEHAV
    end

    QUAL --> REQ["Стабильные требования"]
    DECOMP --> REQ
    BEHAV --> REQ
    REQ --> ADR["ADR при выборе альтернатив"]

Практикум

  1. Рефакторинг scope. Возьмите фрагмент спецификации: одну формулировку упростите (KISS), одну «на будущее» вынесите из Must (YAGNI), одно дублирующееся правило сведите к одному месту с ссылками (DRY).
  2. GRASP на сущности. Для «Заказ» / «Платёж» / «Клиент» ответьте: Information Expert для расчёта, Creator для дочерних объектов, Controller для входящего события. Зафиксируйте на черновике sequence или use case.
  3. Интеграционный выбор. Опишите сценарий «событие A → система B» с критериями: нужен ли ответ сразу, допустима ли eventual consistency, кто ещё подписан. Сопоставьте с одной строкой таблицы интеграционных сценариев выше.
  4. SOLID и ADR. Для спорного расширяемого API выпишите: что требование (поведение для заказчика), что ADR (выбор plug-in vs жёсткая интеграция), как KISS ограничивает OCP в текущем релизе.
  5. Критерии приёмки. Перепишите один критерий так, чтобы по KISS/YAGNI его можно было проверить без «на будущее» и скрытых допущений.

4. Типовые ошибки и ограничения

  • Принципы как декорация. KISS/YAGNI/DRY цитируют, но scope и бэклог не режут — принцип без артефакта (02.01.04 Определение границ решения (Scope Modelling), 02.03.02 Приоритизация требований (MoSCoW, WSJF, Кано)) бесполезен.
  • DRY через насильственное слияние контекстов. Разные bounded context требуют разных моделей; одна универсальная сущность ломает смысл терминов.
  • Information Expert vs enterprise master data. DRY тянет к «единому клиенту» на всю корпорацию, а Expert говорит: расчёт скидки — у «Заказа», мастер-данные — у MDM. Спор решают явной границей владения данными, а не слиянием моделей.
  • GRASP и SOLID «для разработчиков». Если в спецификации не видно, кто за что отвечает, паттерны не применены — проверяйте на ревью требований (08.04 Рецензирование и инспекции (техники Фейгана)).
  • EIP без SLA. «Через очередь» без требований к доставке, повтору и идемпотентности — не спецификация, а пожелание.
  • Перегруз DDD в фундаменте. Entity/VO/Domain Service в деталях дублируют 03.06.02 Основы Domain-Driven Design — здесь достаточно языка, контекста и агрегата.
  • Конфликты без решения. KISS vs OCP, DRY vs автономия команд, YAGNI vs страх «переделывать» — фиксируйте явно в ADR или протоколе решения (01.04 Теория игр для аналитика), иначе команда получит противоречивые требования.
  • Scope creep под видом расширяемости. Open/Closed не оправдывает фичи вне приоритета — см. 02.05.03 Управление объёмом (Scope Creep) и ожиданиями.

Связи с другими разделами базы

Источники и дополнительные материалы

Книги и стандарты

  • Craig Larman. Applying UML and Patterns (3rd ed., 2004). GRASP и связь анализа с паттернами. Amazon
  • Eric Evans. Domain-Driven Design (2003). Ubiquitous Language, Bounded Context, Aggregate. Amazon
  • Gregor Hohpe, Bobby Woolf. Enterprise Integration Patterns (2003; доп. издания 2025). Каталог EIP и сайт с описаниями паттернов: enterpriseintegrationpatterns.com
  • Robert C. Martin. Clean Architecture (2017). SOLID и архитектурные границы. Amazon

Статьи и онлайн-каталоги