[{"data":1,"prerenderedAt":137},["ShallowReactive",2],{"content:\u002F06-architecture\u002F00-intro":3},{"title":4,"description":5,"path":6,"body":7},"Введение в архитектуру Go-сервисов","Этот модуль про то, как удерживать проект понятным, когда файлов становится много, зависимостей больше одной, а требования начинают меняться. Архитектура здесь не про красивые схемы, а про стоимость изменений.","\u002F06-architecture\u002F00-intro",{"type":8,"value":9,"toc":129},"minimark",[10,14,17,20,23,28,50,52,56,70,73,76,100,102,106,109,112,114,118],[11,12,4],"h1",{"id":13},"введение-в-архитектуру-go-сервисов",[15,16,5],"p",{},[15,18,19],{},"В Go архитектурные подходы обычно выглядят проще, чем в Java-мире: меньше наследования, больше явных интерфейсов, пакетов и функций. Но простота не отменяет дисциплину. Если границы не обозначены, бизнес-логика быстро смешивается с HTTP, базой, очередями и случайными деталями инфраструктуры.",[21,22],"hr",{},[24,25,27],"h2",{"id":26},"что-будет-внутри","Что будет внутри",[29,30,31,35,38,41,44,47],"ul",{},[32,33,34],"li",{},"layered architecture как базовая точка отсчёта;",[32,36,37],{},"hexagonal и onion architecture: ports, adapters, направление зависимостей;",[32,39,40],{},"Clean Architecture и практическая раскладка по пакетам;",[32,42,43],{},"сравнение подходов без попытки выбрать один навсегда;",[32,45,46],{},"DDD: язык предметной области, entities, value objects, aggregates;",[32,48,49],{},"паттерны, которые в Go действительно встречаются в живом коде.",[21,51],{},[24,53,55],{"id":54},"как-теория-связана-с-проектом-ratedesk","Как теория связана с проектом RateDesk",[15,57,58,59,64,65,69],{},"Теоретические уроки разбирают архитектурные решения отдельно: layered, ports\u002Fadapters, use cases, DDD, aggregates, patterns. Практическая сборка этих решений живёт в отдельном проектном треке ",[60,61,63],"a",{"href":62},"\u002Fprojects\u002Fratedesk","RateDesk",", особенно на этапе ",[60,66,68],{"href":67},"\u002Fprojects\u002Fratedesk\u002Farchitecture","Architecture",".",[15,71,72],{},"Поэтому в уроках ниже будут короткие production-примеры и анти-примеры, а не полноценные проектные задания. Детальные issue, acceptance criteria, MR-план, ADR и review checklist должны жить в проекте, где студент реально меняет код.",[15,74,75],{},"Связка простая:",[29,77,78,81,89],{},[32,79,80],{},"в теории студент понимает правило и видит небольшой пример;",[32,82,83,84,88],{},"в RateDesk применяет правило к ",[85,86,87],"code",{},"ConvertAmount",", rate provider, repository boundary, config, idempotency и outbox;",[32,90,91,92,95,96,99],{},"на review проверяет не «похожесть на Clean Architecture», а конкретные свойства: нет циклов импортов, use case тестируется без БД, домен не знает про ",[85,93,94],{},"pgx",", ",[85,97,98],{},"echo",", Redis, Kafka и внешние SDK.",[21,101],{},[24,103,105],{"id":104},"как-понять-что-модуль-освоен","Как понять, что модуль освоен",[15,107,108],{},"Вы можете объяснить, почему один пакет зависит от другого, где живёт бизнес-правило и что нужно изменить при замене базы, HTTP-фреймворка или внешнего клиента. Вы не создаёте слои ради слоёв, но и не складываете всё в один handler.",[15,110,111],{},"Главный результат: вы умеете выбирать структуру под размер задачи. Маленькому сервису не нужна тяжёлая церемония, большому сервису опасно жить без границ.",[21,113],{},[24,115,117],{"id":116},"рабочие-ориентиры","Рабочие ориентиры",[29,119,120,123,126],{},[32,121,122],{},"Архитектура должна защищать важные правила от деталей доставки и хранения.",[32,124,125],{},"Интерфейс обычно объявляет потребитель, а не поставщик.",[32,127,128],{},"Чем дороже изменение, тем явнее должна быть граница вокруг него.",{"title":130,"searchDepth":131,"depth":131,"links":132},"",2,[133,134,135,136],{"id":26,"depth":131,"text":27},{"id":54,"depth":131,"text":55},{"id":104,"depth":131,"text":105},{"id":116,"depth":131,"text":117},1781022065700]