Все архитектуры +- сводятся к тому что основная их задача защитить домен от внешних факторов. Разница в том как они это делают. На практике в коде если ты явно не розделяешь это на уровне неймспейсов/папок то они могут выглядеть практически одинаково
Hexagonal - делит представления на две части порты и адаптеры. Домен является портом в виде интерфейсов, а адаптеры реализуют связь с внешним миром.
Clean Architecture - берёт ту же идею но добавляет явные слои которые ты видешь в виде колец + строгое соблюдения зависимостей.
Да. Могу с уверенностью сказать: чем подробнее и структурированнее у тебя README, тем лучше агент справляется с задачей. Это легко проверить на практике.
ИИ не “понимает проект магически” — он ориентируется на контекст. Каждый новый запрос для него - как чистый лист. По сути, README становится частью “операционной памяти” модели. Чем меньше неявных договорённостей в голове у разработчика и больше явных правил в тексте — тем лучше результат.
Тут ещё важно понимать, что такое контекстное окно. У любой модели есть ограниченный объём “памяти” в рамках сессии. Когда контекст разрастается (файлы, диффы, логи, обсуждения), он начинает занимать всё окно. И если оно забито на 60%+, модель уже начинает терять фокус. Поэтому нужно чистить контекст, начинать новые сессии для крупных задач в новом или чистом окне, не тащить в один поток 10 разных не свзязаных задач.
Роль «просто писать код руками» уже занята за $20 ИИ уже генерирует быстрее и лучше. Если ты junior и вообще не кодил руками — ты не сможешь быть «архитектором» и даже нормально проверить код модели. Чтобы валидировать ИИ, нужны знания. Без этого ты не инженер, а prompt-оператор.
Сейчас ценность не в «уметь печатать код», а в: системном мышлении, заннии архитектуры, умении читать и понимать код, готовность нести ответственности за прод и не важно кто его написал. ИИ — это только ускоритель который можно/нужно использовать чтобы быстрее прокачать свои скилы.
Мне удалось. Я перенес много чего в README.MD и ARCHITECTURE.MD а в CLAUDE прошу его читать эти файлы перед запросами агенту и редактирвоать их для того чтобы были актуальные
Интересный опыт. У меня он обратный. Часто сталкиваюсь что весь контекст не может ИИ в себя поместить и сам апи видает ошибку и ей приходиьсья читать файл кусками и при редактировании те же проблемы. Тоесть я потратил 2000 токено и потом ошибка и так 3-4 раза пока модель не поняла что нужно по 200 строк читать;
Когда-то и кросс-платформенная компиляция под несколько ОС казалась фантастикой, а сегодня это уже обыденность. Поэтому я бы не стал так быстро списывать Spec-as-Source со счетов — возможно, мы просто находимся на очень раннем этапе развития этой парадигмы.
По поводу текущих SDD-фреймворков согласен — они пока выглядят довольно сырыми и явно не дотягивают до заявленных амбиций. Но это не значит, что сама идея нежизнеспособна. Скорее, реализация оказалась сложнее, чем ожидалось.
Да. хорошее замечания. Ставка была на будущее. Active support 8.4-8.5 команды будут отлично работать на 8.4 я обвновю composer спасибо. Также есть идея превратить все это в claude plugin
Это один из скилов acc-documentation-writer.md который используеться для описании документации. Для аудита и генерации посильнее описаны. Но спсибо за фитбек. Я создал базу, новых вич пока не будет; Ближайшие n версий пакета буду его одтачивать и тестировать. Посмотрю как лучше описать acc-architecture-doc-template
Я не понял failed-очереди все же стоит использовать или нет? Вы сначала говорите что не стоит использовать а потом пишете что у каждого важного транспорта своя failed-очередь
И да и нет. Для удобства и навигации роут сервис или темплейт лучше искать в том домене которому он пренадлежить а не строить структуру папок в конфиге.
Все архитектуры +- сводятся к тому что основная их задача защитить домен от внешних факторов. Разница в том как они это делают. На практике в коде если ты явно не розделяешь это на уровне неймспейсов/папок то они могут выглядеть практически одинаково
Hexagonal - делит представления на две части порты и адаптеры. Домен является портом в виде интерфейсов, а адаптеры реализуют связь с внешним миром.
Clean Architecture - берёт ту же идею но добавляет явные слои которые ты видешь в виде колец + строгое соблюдения зависимостей.
По поводу адаптеоров - так они есть что в той что в другой архитектурe - https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html
И это как раз то что их роднит. Потому что как я писал выше у них одна концепция.
Что именно из визуализации не понятно?
Да. Могу с уверенностью сказать: чем подробнее и структурированнее у тебя README, тем лучше агент справляется с задачей. Это легко проверить на практике.
ИИ не “понимает проект магически” — он ориентируется на контекст. Каждый новый запрос для него - как чистый лист. По сути, README становится частью “операционной памяти” модели. Чем меньше неявных договорённостей в голове у разработчика и больше явных правил в тексте — тем лучше результат.
Тут ещё важно понимать, что такое контекстное окно. У любой модели есть ограниченный объём “памяти” в рамках сессии. Когда контекст разрастается (файлы, диффы, логи, обсуждения), он начинает занимать всё окно. И если оно забито на 60%+, модель уже начинает терять фокус. Поэтому нужно чистить контекст, начинать новые сессии для крупных задач в новом или чистом окне, не тащить в один поток 10 разных не свзязаных задач.
Роль «просто писать код руками» уже занята за $20 ИИ уже генерирует быстрее и лучше. Если ты junior и вообще не кодил руками — ты не сможешь быть «архитектором» и даже нормально проверить код модели. Чтобы валидировать ИИ, нужны знания. Без этого ты не инженер, а prompt-оператор.
Сейчас ценность не в «уметь печатать код», а в: системном мышлении, заннии архитектуры, умении читать и понимать код, готовность нести ответственности за прод и не важно кто его написал. ИИ — это только ускоритель который можно/нужно использовать чтобы быстрее прокачать свои скилы.
Мне удалось. Я перенес много чего в README.MD и ARCHITECTURE.MD а в CLAUDE прошу его читать эти файлы перед запросами агенту и редактирвоать их для того чтобы были актуальные
Интересный опыт. У меня он обратный. Часто сталкиваюсь что весь контекст не может ИИ в себя поместить и сам апи видает ошибку и ей приходиьсья читать файл кусками и при редактировании те же проблемы. Тоесть я потратил 2000 токено и потом ошибка и так 3-4 раза пока модель не поняла что нужно по 200 строк читать;
Идея мне, честно говоря, очень зашла.
Когда-то и кросс-платформенная компиляция под несколько ОС казалась фантастикой, а сегодня это уже обыденность. Поэтому я бы не стал так быстро списывать Spec-as-Source со счетов — возможно, мы просто находимся на очень раннем этапе развития этой парадигмы.
По поводу текущих SDD-фреймворков согласен — они пока выглядят довольно сырыми и явно не дотягивают до заявленных амбиций. Но это не значит, что сама идея нежизнеспособна. Скорее, реализация оказалась сложнее, чем ожидалось.
Да. хорошее замечания. Ставка была на будущее. Active support 8.4-8.5 команды будут отлично работать на 8.4 я обвновю composer спасибо. Также есть идея превратить все это в claude plugin
Это один из скилов acc-documentation-writer.md который используеться для описании документации. Для аудита и генерации посильнее описаны. Но спсибо за фитбек. Я создал базу, новых вич пока не будет; Ближайшие n версий пакета буду его одтачивать и тестировать. Посмотрю как лучше описать acc-architecture-doc-template
Я не понял failed-очереди все же стоит использовать или нет?
Вы сначала говорите что не стоит использовать а потом пишете что у каждого важного транспорта своя failed-очередь
Круто! Успехов вам! Много чего вижу переделали в хорошую сторону и это радует
Пример даже сделали с нотками DDD и чистой архитектуры ;)
В команде у нас на основном проекте такая структура + порядка 10-ти микросервисов тоже такая структура; Нет проблеем с фичами и костылей тоже нету.
И да и нет. Для удобства и навигации роут сервис или темплейт лучше искать в том домене которому он пренадлежить а не строить структуру папок в конфиге.
да все верно. думаю это не суть важно. никто не говорит что слоев может быть только 4; Решил отделить, но можно положить и в инфраструктуру
#[ORM\Embeddable] - тут согласин некоторые вещи сделаны просто для удобства и простоты использования
Спасибо за замечания.
Ну если Пелевин был прав — значит, у меня уже готово портфолио для должности корпоративного клоуна
Согласен. Подскажите более актуальную тематику и я поменяю на нее
Спасибо. Отредактировал. Добавил понятия пассивного и активного MVC чтобы избежать путаницы
Спасибо. Отредактировал. Добавил понятия пассивного и активного MVC