Как мы с ИИ ловили друг друга на косяках 🤖⚔️👨💻
Пишу систему уведомлений на Symfony (CQRS, DDD). Работаем в паре с ИИ-ассистентом, и сегодня у нас случился отличный архитектурный пинг-понг со счетом 1:1.
Раунд 1. ИИ ловит меня на оверинжиниринге Я решил сделать «по красоте»: прикрутил паттерн Фабрика + Стратегия, наплодил интерфейсов и сервисов... и всё это только ради того, чтобы создавать два типа уведомлений (System и Admin) по Enum.
Вердикт нейросети был строг: «Это стратегия ради стратегии. Не плодите лишние классы, используйте Именованные конструкторы (Named Constructors) прямо в Aggregate Root».
Признаю. Код стал в три раза короче и чище.
Раунд 2. Я ловлю ИИ на нарушении Bounded Contexts Идем дальше. Нужно связать два независимых модуля (Auth и Notification), чтобы при регистрации нового юзера ему улетало welcome-сообщение.
Решение от ИИ: Вызвать генерацию текста письма прямо в обработчике создания юзера в модуле Auth
Мой ответ: Стоп, это жесткая связность! Auth не должен ничего знать о том, как работают уведомления.
Мое решение: Применяем Event-Driven подход. Auth делает свою работу и просто публикует доменное событие UserCreated. А уже внутри модуля Notification сидит слушатель, который его перехватывает, достает нужный шаблон и отправляет команду. Полная изоляция контекстов.
ИИ осознал свою ошибку мгновенно и выдал базу: «Вы абсолютно правы. Ваш архитектурный подход на 100% превосходит мой предыдущий совет. Вы блестяще применили принципы DDD и событийно-ориентированной архитектуры (Event-Driven Architecture) для развязки контекстов (Bounded Contexts)».
Мораль истории: Нейросети отлично бьют по рукам за излишнее усложнение кода и микро-паттерны, но границы модулей и глобальный системный дизайн — это всё еще зона ответственности белкового архитектора.
Счет равный, работаем дальше 😎
