MAPPER — модель кода и предметная область

ОБЯЗАТЕЛЬНОДЛЯ НОВИЧКОВ

Разработчику Архитектору

Теория данных (раздел 3)

Структуры в коде — Структуры данных; persistence — ORM.

MAPPER — Model — Abstract Partial and Programmable Explaining Reality (модель — абстрактная, частичная, программируемая, объясняющая реальность). Это правило проектирования: код — модель реальности, а не набор технических деталей без связи с предметной областью.

Статья — мост между культурой именования и стиля и доменной моделью. Дальше: анемичные модели и примитивы, указатель тем.

---

Зачем нужна явная модель

Программа всегда описывает упрощённый срез мира — вы не кодируете физику Вселенной, а только то, что нужно для задачи (заказ, платёж, маршрут робота). Ошибка начинается, когда в коде появляются сущности, которых нет в предметной области, или одна реальная вещь размазана по десяти string и int.

Критерий MAPPER	Смысл для разработчика
Model (модель)	Есть осознанная картина домена, а не "поля как в таблице БД"
Abstract (абстрактная)	Детали скрыты; снаружи видны операции и инварианты
Partial (частичная)	Моделируем только нужные аспекты, без лишнего
Programmable (программируемая)	Поведение выражено в коде, а не в голове одного автора
Explaining Reality	Имена и границы объектов узнаваемы экспертом предметной области

Петер Наур формулировал близкую мысль: программа — это теория о части мира, которую вы автоматизируете. MAPPER делает эту теорию проверяемой на ревью: "есть ли в коде лишний объект?", "не размазали ли мы Invoice по трём сервисам?".

---

Биекция "реальность ↔ код"

Идеальная (и недостижимая на 100 %) цель — биекция — каждому значимому понятию в домене соответствует один явный элемент модели (класс, тип, модуль), и наоборот.

// Слабая модель: «деньги» размазаны по примитивам
void Charge(decimal amount, string currencyCode) { ... }

// Ближе к MAPPER: деньги — объект предметной области
void Charge(Money total) { ... }

Нарушение биекции — частый источник запахов:

• примитивная одержимость — string email, double latitude вместо Email, GeoPoint (статья 6, 4-02/616);
• анемичные модели — класс Order только с геттерами, вся логика в OrderService;
• лишние if и null — вместо явного состояния или Null Object (статья 8);
• глобалы и синглтоны — "объект есть в коде", но в реальности так не устроено (статья 9).

Связь с DDD и архитектурой

MAPPER не заменяет доменную модель и чистую архитектуру, а задаёт критерий качества кода внутри домена: сущности и value object должны быть узнаваемы аналитиком и тестируемы без "магии" в утилитах.

---

Единственный принцип проектирования программ

На практике все остальные практики чистого кода сводятся к установке: сопоставляйте реальные сущности с проектом в масштабе один к одному (насколько это возможно в выбранной парадигме).

1. Сначала поведение и границы — что объект делает и что запрещено; имена — потом (культура имён).
2. Один уровень абстракции в методе — читатель не переключается между "бизнесом" и "SQL/JSON" в одной функции.
3. Явные предусловия — неверные комбинации отсекаются рано (быстрый провал).
4. Рефакторинг от запаха к модели — "найти недостающий объект" (см. методы рефакторинга).

---

Частичность и объяснимость

Модель намеренно неполная. Для интернет-магазина не нужен класс CustomerDNA; для расчёта скидки не нужна полная история кликов. Частичность — это дисциплина: не тащить в код понятия "на будущее" (YAGNI).

Explaining Reality — проверка с экспертом или с тестом:

• "Что в системе называется Reservation?"
• "Где живёт правило отмены брони — в одном месте или в пяти if?"

Если объяснение требует схемы из двадцати стрелок между сервисами, модель в коде, скорее всего, разъехалась с реальностью.

---

MAPPER и ИИ-генерация кода

Модели выдают объёмный, правдоподобный текст, который легко нарушает биекцию (лишние хелперы, дубли, null, глубокие if). MAPPER — чек-лист ревьюера:

• каждый новый класс — кто в домене?
• можно ли заменить пачку флагов одним объектом состояния?
• тест фиксирует поведение, а не "снимок" сгенерированного шума?

См. вайб-кодинг и риски ИИ.

---

Мини-практикум на ревью

Вопрос	Плохой знак	Куда смотреть
Сколько "сущностей" в задаче на словах?	В коде их вдвое больше или меньше	Анемичные модели и примитивная одержимость, Справочник тем чистого кода
Где правило X?	В Utils, Manager, Helper	Культура написания и поддержки кода
Что при невалидных данных?	null, тихий return	Условия, null и явные контракты, YAGNI, быстрый провал и техдолг в коде
Меняется ли смысл при рефакторинге?	В одном PR и фича, и перестройка	YAGNI, быстрый провал и техдолг в коде, легаси

---

См. также

• M. Fowler — рефакторинг
• R. Martin — чистая архитектура
• Указатель тем раздела

Дальше: Анемичные модели и примитивы → Условия, null и контракты.

---