В этом видео:
Данный урок помогает взглянуть на привычные подходы к проектированию приложений в динамике: от первых шагов с MVC (Model-View-Controller) до зрелых решений по типу Domain-Driven Design (DDD) и Clean Architecture (Чистая архитектура). Автор не ограничивается сухим объяснением, а показывает и дает понимание, как меняются требования к структуре кода и организации системы по мере того, как растёт продукт, команда и сама бизнес-логика.
В начале речь идет о том, почему проектирование имеет значение, даже если у тебя уже есть рабочий продукт. На этапе MVP всё выглядит просто: код небольшой, фичи добавляются быстро, и кажется, что дополнительных правил не нужно. Но как только команда увеличивается и растёт число задач, появляются знакомые проблемы: слишком много зависимостей, трудности с поддержкой и взаимодействием, увеличение стоимости любых изменений. Именно в этот момент становится ясно, что без продуманной архитектуры систему сложно поддерживать и развивать. Расскажем о ключевых задачах и принципах хорошей архитектуры для разработки сервисов.
Затем подробно разбирается MVC. Этот архитектурный шаблон удобен для небольших веб-приложений: модель отвечает за данные, контроллер — за обработку запросов и действий, представление — за отображение интерфейса пользовательского. Использование MVC позволяет быстро создать прототип, легко разделить отдельных компонентов и понять, где какой функционал входит в систему. Но вместе с ростом продукта начинают размываться границы: объекты бизнес-логики смешиваются с контроллерами, а код становится труднее править и расширять.
Далее автор переходит к DDD как способу «структурировать хаос». Основная мысль в том, что проектирование должно строиться вокруг предметной области, а не вокруг UI или базы данных. Здесь используются концепции единого языка, bounded context, сущности, value objects, событий, use cases и repository. Такой подход помогает разделить систему на модули с чёткими границами, понять следующие зависимости и правильно организовать работу с данными. Благодаря этому команда может легче найти нужное место в проекте и управлять компонентами независимо друг от друга.
Финальная часть посвящена Clean Architecture (Чистая архитектура) Роберта Мартина. Здесь зависимости направлены внутрь, к домену, а инфраструктура, базы, UI и сторонние технологии вынесены наружу. Слои чётко определены: сущности, сценарии использования, адаптеры интерфейсов и инфраструктура. Такой подход делает код устойчивым к изменениям и позволяет безболезненно обновлять приложения, добавлять новые функции для пользователя. Clean Architecture помогает правильно организовать реализацию и использование системы на долгие годы.
Если ты уже сталкивался со сложностями разрастающихся монолитов и хочешь понять, какие архитектурные практики реально работают, это видео для тебя. Оно полезно разработчикам уровня middle и senior, которые думают не только о том, как быстро реализовать фичу, но и о том, как построить систему, которую можно легко поддерживать, расширять и развивать в рамках компании.
This lesson helps you see how applications evolve from simple prototypes into more complex systems. Using the MVC (Model-View-Controller) pattern, you can quickly create a simple prototype. The model handles data, the controller handles actions, and the view displays the interface for the user. This structure makes it easy to separate components, but as the product grows, boundaries blur, and some business logic mixes into controllers, making it harder to handle changes.
Later, with the Domain-Driven Design (DDD) approach, the focus shifts to the domain. Each entity, value object, and use case is clearly defined. Teams can find the right place for each function and update the system without breaking other parts. Events and repositories help handle dependencies correctly, so you can return more predictable behavior.
Finally, using the Clean Architecture type by Robert Martin, dependencies point inward, to the domain, while UI, infrastructure, and databases are external. Layers include entities, use cases, interface adapters, and infrastructure. This structure makes code more maintainable and allows teams to create new features without expensive changes.
If you have faced growing monoliths, this video is best for understanding how some architectural practices really work. Developers like middle and senior engineers can follow these patterns to make systems easier to update, scale, and maintain over time. Importantly, all examples are available on GitHub, so you can review the code, name functions clearly, and follow best practices.
- 00:00 — Введение
- 11:51 — MVC
- 26:23 — Domain-driven design
- 43:03 — Чистая архитектура
- 54:20 — Курс по микросервисам, как в BigTech
Данный урок помогает взглянуть на привычные подходы к проектированию приложений в динамике: от первых шагов с MVC (Model-View-Controller) до зрелых решений по типу Domain-Driven Design (DDD) и Clean Architecture (Чистая архитектура). Автор не ограничивается сухим объяснением, а показывает и дает понимание, как меняются требования к структуре кода и организации системы по мере того, как растёт продукт, команда и сама бизнес-логика.
В начале речь идет о том, почему проектирование имеет значение, даже если у тебя уже есть рабочий продукт. На этапе MVP всё выглядит просто: код небольшой, фичи добавляются быстро, и кажется, что дополнительных правил не нужно. Но как только команда увеличивается и растёт число задач, появляются знакомые проблемы: слишком много зависимостей, трудности с поддержкой и взаимодействием, увеличение стоимости любых изменений. Именно в этот момент становится ясно, что без продуманной архитектуры систему сложно поддерживать и развивать. Расскажем о ключевых задачах и принципах хорошей архитектуры для разработки сервисов.
Затем подробно разбирается MVC. Этот архитектурный шаблон удобен для небольших веб-приложений: модель отвечает за данные, контроллер — за обработку запросов и действий, представление — за отображение интерфейса пользовательского. Использование MVC позволяет быстро создать прототип, легко разделить отдельных компонентов и понять, где какой функционал входит в систему. Но вместе с ростом продукта начинают размываться границы: объекты бизнес-логики смешиваются с контроллерами, а код становится труднее править и расширять.
Далее автор переходит к DDD как способу «структурировать хаос». Основная мысль в том, что проектирование должно строиться вокруг предметной области, а не вокруг UI или базы данных. Здесь используются концепции единого языка, bounded context, сущности, value objects, событий, use cases и repository. Такой подход помогает разделить систему на модули с чёткими границами, понять следующие зависимости и правильно организовать работу с данными. Благодаря этому команда может легче найти нужное место в проекте и управлять компонентами независимо друг от друга.
Финальная часть посвящена Clean Architecture (Чистая архитектура) Роберта Мартина. Здесь зависимости направлены внутрь, к домену, а инфраструктура, базы, UI и сторонние технологии вынесены наружу. Слои чётко определены: сущности, сценарии использования, адаптеры интерфейсов и инфраструктура. Такой подход делает код устойчивым к изменениям и позволяет безболезненно обновлять приложения, добавлять новые функции для пользователя. Clean Architecture помогает правильно организовать реализацию и использование системы на долгие годы.
Если ты уже сталкивался со сложностями разрастающихся монолитов и хочешь понять, какие архитектурные практики реально работают, это видео для тебя. Оно полезно разработчикам уровня middle и senior, которые думают не только о том, как быстро реализовать фичу, но и о том, как построить систему, которую можно легко поддерживать, расширять и развивать в рамках компании.
This lesson helps you see how applications evolve from simple prototypes into more complex systems. Using the MVC (Model-View-Controller) pattern, you can quickly create a simple prototype. The model handles data, the controller handles actions, and the view displays the interface for the user. This structure makes it easy to separate components, but as the product grows, boundaries blur, and some business logic mixes into controllers, making it harder to handle changes.
Later, with the Domain-Driven Design (DDD) approach, the focus shifts to the domain. Each entity, value object, and use case is clearly defined. Teams can find the right place for each function and update the system without breaking other parts. Events and repositories help handle dependencies correctly, so you can return more predictable behavior.
Finally, using the Clean Architecture type by Robert Martin, dependencies point inward, to the domain, while UI, infrastructure, and databases are external. Layers include entities, use cases, interface adapters, and infrastructure. This structure makes code more maintainable and allows teams to create new features without expensive changes.
If you have faced growing monoliths, this video is best for understanding how some architectural practices really work. Developers like middle and senior engineers can follow these patterns to make systems easier to update, scale, and maintain over time. Importantly, all examples are available on GitHub, so you can review the code, name functions clearly, and follow best practices.
