Знакомо: вы описываете требования, рисуете сущности — Клиент, Заявка, Документ… А потом система превращается в «комок» с сильной связанностью (big ball of mud), где любое изменение стоит как полпроекта?
А что если иногда правильный класс — тот, которого нет в реальности (рядом с предметной областью, а не вместо неё)? Бизнес инварианты остаются в домене. Это не магия, а принцип Pure Fabrication (Чистая выдумка) из GRASP: после оценки по Information Expert помогаем добиться Low Coupling/High Cohesion; вместе с Indirection экранируем изменения (Protected Variations).
Пример из жизни и нашего курса «Объектно-ориентированный анализ и проектирование на UML» (REQ-003):
В кредитном портале нужно логировать действия, валидировать документы и общаться с внешним API. Можно поместить все в класс Заявка — получится «комок», который знает слишком много.
А можно придумать:
AuditLogger — только логи
DocumentValidator — только проверка (бизнес валидация = доменный сервис; форматы/схемы = чистая выдумка)
ExternalApiGateway (Adapter/Facade) — общение с внешним миром и изоляция протоколов
Когда применять (короткий чек лист):
если размещение ответственности в доменном классе роняет связность/растит связанность;
если нужно экранировать внешний ресурс/протокол;
если требуется повторное использование вне конкретной доменной сущности.
Почему это важно для каждой роли в проекте?
Аналитик: проектирует решения, а не просто документирует требования
Архитектор: строит устойчивые системы с ясными абстракциями
Разработчик: получает четкую структуру для реализации
Менеджер: снижает риски и делает оценки надёжнее
Вся команда начинает говорить на одном языке — языке проектирования.
И да, Pure Fabrication — лишь один из 9 принципов GRASP, которые вы освоите, если пройдете наш курс «Объектно-ориентированный анализ и проектирование на UML» (REQ-003). Вместе с паттернами, диаграммами и главным — мышлением проектировщика.
Кому подойдёт курс:
Системным и бизнес-аналитикам, которые хотят влиять на архитектуру
Разработчикам, которые устали от «спагетти-кода»
Архитекторам, которые ищут системный подход
Всем, кто хочет говорить на языке UML и GRASP
Вместо вывода:
Хотите создавать системы, которые не ломаются от каждого нового требования?
Приходите на курс «Объектно-ориентированный анализ и проектирование на UML» (REQ-003). Пока другие собирают требования, вы будете проектировать решения. Пока другие тушат пожары изменений, ваша система принимает их безболезненно.
Вспомните последний проект, где небольшие изменения повлекли за собой большие переделки. Как думаете, можно было это спроектировать иначе?