Проектирование веб приложения | Разработка проекта с нуля — Transcript

Всем привет. Меня зовут Кирилл, и я решил выложить на канал первую часть моего интенсива по архитектуре и структуре дотнето приложения, которое я ещё давно записал, которое уже давно можно приобрести в моём Telegram-канале, там ссылки все есть в описании. В общем,

подписывайтесь, ставьте лайки и приятного просмотра. Если вы его посмотрите и вам понравится, то вы можете подумать, нужен ли он вам и хотите ли его приобрести. Так что приятного вам просмотра. Всем привет.

Всё, запись начал. Меня зовут Кирилл. Добро пожаловать на мой интенсив по архитектуре и структуре .NET приложений. Соответственно, что на нём будет, сейчас я кратко расскажу о примерном плане этого интенсива, что мы будем на нём делать и для кого он нужен.

Соответственно, буду я двигаться медленно, планомерно, всё объясняя потихоньку, все темы разжёвывая, чтобы все всё поняли. Соответственно, будет и практика, и теория, и репозиторий открыты, всё это будет. Давайте сначала вкратце о планах, что вообще на нём будет и почему я выбрал именно такую

тему для первого интенсива. А дело в том, что многие, очень многие ребята, которые только хотят серьёзно заниматься веб-разработкой, изучать ASP.NET Core, писать приложение на дотнете и, соответственно, дальше искать работу, они сталкиваются с проблемой, что они не могут практиковаться. Им не на

чем просто практиковаться. Они не знают, что они могут вообще в принципе сделать, какой код они могут написать, какой проект они могут создать и как вообще построить всю эту архитектуру, чтобы проект хорошо мог развиваться и масштабироваться. Поэтому мы начнём с

этих тем, которые помогут вам спроектировать, во-первых, придумать идею для этого проекта, потом спроектировать эту идею, а понять вообще, что будет в этом приложении, понять, что оно будет делать, как оно будет примерно устроено. Потом мы разберёмся, какую архитектуру выбрать

для вашего приложения. Там это монолит, модульный монолит, микросервисная архитектура. Мы всё это рассмотрим. Потом мы, соответственно, поймём, какие нам нужны фичи. Мы спроектируем REST app. Мы посмотрим дальше уже начнём всё это реализовывать, посмотрим, как это всё реализовать на практике, где

какой должен располагаться код, какая должна быть в целом архитектура. Разберём чистую архитектуру, зачем она нужна. А разберём вообще все фундаментальные концепции, которые вы можете встретить, в принципе, в любом проекте. И самое главное, мы будем делать это на реальном примере. То есть

мы сейчас придумаем идею, её спроектируем и начнём реализовывать. А плюс я предложу в целом несколько идей. В общем, интенсив будет достаточно большой. Я дальше покажу, как вам настраивать проект для собственной разработки, там, для командной разработки, чтобы проект был очень

красивый, чтобы вы могли разбить его на модули, переиспользовать там, потом выстраивать, добавлять новые сервисы, как вам развивать проект, как вообще создавать задачи, как, короче, начать настоящую работу над таким большим проектом, чтобы вы уже были

готовы к реальной коммерческой работе. Потому что, когда вы придёте на реальную коммерческую работу, вы окунётесь и столкнётесь с реально большим проектом. И чтобы вы были готовы к этому, соответственно, вот для этого и нужен этот интенсив. Но тут будет не

только, естественно, теория, тут будет много и практики. И дальнейшие интенсивы я тоже буду планировать таким же образом. Будем брать большие темы и разбирать их. То есть первая тема — это вот всё, что связано с архитектурой, проектированием, структурой там web

.NET приложения. А дальше мы, наверное, разберём всё, что касается DDD, то есть немножко углубимся в бизнес-логику.

Потом, я думаю, мы разберём, как работать с базой данных, с PostgreSQL, там индексы, таблицы, запросы, вот CQRS, то есть вот это всё мы тоже разберём обязательно, всё, что касается базы данных. И дальше мы, думаю, уже будем

выбирать какие-то более точечные темы, например, авторизация и аутентификация, потом микросервисы, в общем, интенсивов будет много.

И каждый из них будет, соответственно, какой-то определённой теме назначен. Ну давайте начнём. А соответственно, с чего я хотел начать, да? Все, когда мы начинаем разрабатывать что-то новое, хотим придумать какую-то идею. И вообще, что можно придумать, что можно

разрабатывать, что делают на дотнете, что делают на ASP.NET Core, какие проекты вообще можно сделать, какие они бывают.

Давайте это сейчас и разберём. Значит, первый вопрос вообще, какие бывают проекты, что можно сделать или как там придумать идею, да? А смотрите, есть два вида проектов. Первый вид — это проекты, которые направлены на клиентов, на людей. Они общедоступные. Это ВК, там

Ozon, Wildberries, не знаю, YouTube, а Twitch. Это такие проекты, которые пользуются люди. И там большая идёт нагрузка. Очень много людей ими пользуются. Это какие-то социальные сети, интернет-магазины. То есть они общедоступные. Тут, я думаю, всё понятно, да? А вы берёте любую идею. То

есть вы выступаете в роли бизнесмена. Здесь, да, вы должны придумать какую-то идею и реализовать её. То есть это может быть какая-то интернет-площадка там по бронированию билетов, это может быть бронирование и регистрация спортплощадок, чтобы там назначать совместные тренировки, игры.

А чтобы предоставлять ваше приложение вот это вот различным спортивным комплексам, и они могли там свою площадку куда-то выложить, а обычные люди могли там пойти зарегистрировать себе, забронировать корт или что-то в этом роде. Это может быть, не знаю, приложение по

управлению компьютерным клубом, но это уже немножко, это уже ближе ко второму виду. Вот второй вид приложений — это приложения, которые работают внутри компании. То есть коммерческие, они нужны для того, чтобы управлять бизнесом каким-то. То есть есть, допустим, тот же

самый Ozon. И представляете, насколько он огромный у них, или Яндекс, да, у них есть очень много внутренних приложений, которые нужны для сотрудников. Там приложение по найму сотрудников, приложение для учёта времени, возможно, сотрудников, там приложение для, что

ещё там может быть именно внутри, да, там работа с документами, документооборот какой-то. То есть очень много, на самом деле, всего можно придумать. И вот есть два вида. И в идеале, чтобы ваш проект затрагивал что-то и из одного вида, и из второго

вида. Скорее всего, когда вы устроитесь на работу, вы будете работать над вторым видом, то есть что-то делать внутри компании. Ну либо какое-то приложение, которое вы будете поставлять конкретному клиенту. Допустим, у меня из опыта моего в одной компании я работал, которая

работала с клиентом, который управлял видеонаблюдением по всему городу. То есть было очень-очень много у него камер, и нужно было написать приложение, которое берёт видеопоток со всех камер. Значит, можно было посмотреть, где какая камера находится, посмотреть с неё видео,

посмотреть архив, посмотреть, какие события она фиксирует. Ну и, как понимаете, для этого нужно целое большое веб-приложение, которое позволяет вам всё это администрировать и всем этим управлять. А другой, другой у меня был опыт, это, например, мы делали платформу для управления и регистрации различных звонков, опросов по телефону. Там чаще всего это было на медицинскую тему. То есть сотрудник должен был увидеть, кому когда звонил телефонный помощник, какие там были симптомы указаны, кто на что жаловался, там список клиентов, ну и

вот в таком роде. То есть это вот ближе ко второму, да, приложению внутри

какой-то компании для сотрудников. Какие могут быть, ну вот для вас, да, какие могут быть примеры приложений? Смотрите, вы можете придумать какую-то любую идею. Вот

представьте, вы открываете бизнес либо что-то хотите реализовать. А соответственно, как придумать идею? Во-первых, стоит обратить внимание на то, что вам не хватает в жизни. Ну, допустим, вот я недавно столкнулся с проблемой. Я хотел поиграть в большой теннис. Я занимался в детстве...

много большим теннисом. хотел поиграть большой теннис и заметил, что очень неудобно искать корты, очень неудобно искать там тренеров, площадок. Я такой подумал: "Блин, было бы прикольно, если было бы какой-то сайт был или было бы приложение, а, которое позволяет вам

посмотреть все доступные спорт-площадки, посмотреть, где они примерно на карте находятся а посмотреть значит свободные места для бронирования, посмотреть там список тренеров, забронировать какую-то тренировку, там назначить себе партнёра или найти себе партнёра для тренировки. Почему бы и нет? Вот вам и готовая огромная идея. И

причём это может быть приложение так и для общего доступа. Так, и там может быть какая-то внутренняя платформа для управления всем там для, ну, админка, да, для управления там аккаунтами, для управления спортплощадками, там для модерация какая-нибудь. И так можно

развивать э почти любую идею. Допустим, хочу я разработать форум, а где, ну, типа Stack Overflow, где, а, конкретно для Дтнета, где люди смогут приходить, оставлять какую-то проблему, связанную с дотнетом, там, с IPSP corore, там прилагать скриншот и внизу видеть значит

ответы, там помощь какую-то, ну, как OFlow, да, я думаю, все пользовались, и там человек мог выбрать какой-то правильный ответ. При этом там другие комментаторы могли что-то прокомментировать, какую-то оставить реакцию, возможно, ну, то есть положительный рейтинг какой-то был, там

были пользователи и всё в таком роде. И вот этот форум, он может быть частью какого-то более большого приложения.

Приведу вот на своём примере. Мы сейчас на моём курсе, а, разрабатываем большую платформу образовательную, ну, которая будет для меня, да, и для вас в том числе, а где будет много модулей. То есть там будет модуль для просмотра занятий, модуль для выполнения заданий.

Модуль как раз-таки вот этот форум, где люди смогут как какие-то спрашивать вопросы либо, а хотеть увидеть, да, решение их проблем. И, соответственно, вот вы можете придумать какую-то идею, которую можно потом будет раскрутить до каких-то больших масштабов. То есть вы

придумали какой-то форум, потом подумали: "Так, а форум может быть частью чего-то более большого". Или, например, вы можете конкретно посмотреть там на ваш город, посмотреть, вот есть компьютерный клуб, и понять, в нём не очень удобно, не знаю, проходит регистрация. Ну и почему бы и не сделать

ппроект? То есть мы же говорим не о каком-то коммерческом приложении. Сейчас мы говорим о петпроекте. И может быть вообще, в принципе, любая идея. Вы можете взять какую-то готовую идею, полностью её скопировать для себя именно, ну, самостоятельно, то есть взять просто

готовую идею и реализовать, как вы это видите. А, допустим, вот вы видите компьютерный клуб, и вы хотите добавить какое-то удобное приложение, чтобы можно было удобно им управлять. Что там будет?

Там нужно, да, опять же, чтоб, а, администратор этого компьютерного клуба мог зарегистрировать какие-то места, мог там компьютеры зарегистрировать. Вот есть такой такой-то слот, было какое-то расписание, вот слот доступен в такое в такое время, а там, не знаю, список

возможностей для каждого компьютера, какой есть. И дальше там обычно люди могли бы посмотреть вообще список свободных слотов зарегистрироваться купить какой-то абонемент. А очень много уже можно функционала тут реализовать.

Какая-то поддержка, опять же, модерация, короче, очень много уже можно реализовать функционала. И это эту идею можно развивать. Почти для каждой там для каждого приложения можно придумать работу с модерацией, с поддержкой. То есть опять же там компьютерный клуб либо

форум. Человек хочет пожаловаться на этого пользователя, он отправляет жалобу, значит, должен быть модератор, который должен эту жалобу рассмотреть, должен принять какое-то решение, а он должен там как-то связаться с этим пользователем, должны рассылаться уведомления. То есть видите, как уже

много я придумал функционала просто с пустоты. Соответственно, как, а, прийти к тому, ну, как начать проектировать, вот с чего начать, чтобы вообще что-то делать, да, чтобы что-то реализовать, чтобы это не просто так в воздухе летало. Но смотрите, сначала давайте как

поступим. Выберем, ну, я вот сейчас выберу идею для как раз-таки своего проекта, который я буду реализовывать в этом интенсиве, и начнём его проектировать. А вы возьмёте и точно также придумаете свою идею какую-нибудь.

Допустим, это может быть опять же управление компьютерными клубами, управление персоналом по найму, какое-то приложение для найма, а там интернет-магазин, да, вот всё, что угодно придумали. Там, не знаю, вот вы с медициной допустим столкнулись вы хотите там, чтобы можно было удобно

записываться к врачам, просматривать, а, рецепты, там, просматривать список звонков и всего такого. То есть это тоже можно вообще и в любую взять сферу и что-нибудь придумать. Может быть, вы там для себя хотите какую-то автоматизацию добавить. Вы понимаете, вам какой-то

процесс кажется слишком рутинным, и вам было бы намного проще, если бы вы вот вы это реализовали в реальной жизни и использовали бы. То есть всё, что угодно можно придумать. Но на что стоит опираться? Нужно желательно придумывать какие-то идеи и проекты, которые будут

релевантны там для реального мира, то есть в реальном бизнесе. Потому что когда вы будете показывать там или рассказывать, приводить примеры из своего проекта на собеседование, то есть как у меня будет отдельный интенсив по устройство на работу, как вам придумать

легенду, как составить резюме. Ну, в общем, а один там из пунктов вы на основе, то есть вы свой проект позиционируете как коммерческий, над которым вы работали в реальной компании.

Ну, один из вариантов. И вы должны будете перечислять, какие фичи, что вы реализовывали, почему вы так делали и так далее. Соответственно, тематика должна быть примерно такая, схожая с реальным миром, а, с какой-то коммерцией. Поэтому там вот всё, что

касается какого-то расписания, бронирования, учёт времени, а может быть там платформа образовательная там, да, часто тоже сейчас они появляются, форум какой-то, управление этим форумом там для внутренних сотрудников там. И, конечно, можно придумать всё, что угодно потом в легенде, всё равно основываясь

на вашем проекте. Но вот что-то нужно такое придумать, чтобы это было релевантно в реальном мире. Вот я несколько примеров привёл.

Давайте я сейчас более конкретные приведу примеры, которые я уже успел посмотреть тут себе выписать. Значит, это вот платформа для регистрации и бронирования спорт-площадок. Об этом говорил платформа для найма сотрудников внутри какой-то компании. платформа для учёта времени этих сотрудников, чтобы

каждый сотрудник мог сказать: "Вот я сегодня поработал столько-столько-то". Да. А и, допустим, платформа для бронирования билетов там на какие-то, э, мероприятия, возможно, да? А может быть, а, платформа по, э, созданию какого-то мероприятия и там, чтобы вы могли опубликовать информацию о каком-то

мероприятии, там стоимость, во сколько оно проводится и так далее, чтобы разослалось им уведомления пришли и так далее.

Либо это может быть опять же форум какой-нибудь, а мини-социальная сеть для узкого круга людей, управление денежными своими средствами, допустим, да? То есть вы хотите там, а, каким-то образом более принести, ну, привести порядок ваши денежные средства, чтобы контролировать их траты и так далее. Почему там вы её

там куда-то в инвестиции вложили, там вы это отложили просто деньги, это вы потратили, то вы планируете потратить, почему бы и нет, почему бы не придумать для этого веб-приложение.

Ну так вот, давайте выберем тогда идею сейчас более конкретную и начнём её реализовывать. То есть стек наш таков, да, это вот IPCE и клиент в роли клиента. То есть мы будем делать вебпи приложение и в роли клиента будет

выступать фронтEND. А на там реакте либо ангуляре, неважно чём. ФНENД мы делать не будем, только backend. И, ну, пока что, по крайней мере, в этом интесиве. И а делать мы будем именно веб-апе. Мы не будем делать MVC, потому что я к этому

так себе отношусь. Потому что сейчас самое актуальное, что всё, вот самое прямо актуальное, а, в современном мире, в современных реалиях - это именно вебИ, написание каких-то проектов, микросервисов, сервисов, именно апии, с который с которыми можно коммуницировать через HTTP, ну, либо брокер сообщений,

а, либо там JRPC, например. То есть все эти темы опять же мы будем разбирать потом когда-нибудь. Так что давайте начнём это проектировать. Что это будет вообще за приложение? Что такое вообще веб-приложение и что такое а? В общем, у

нас будет находиться кэнд на нашем сервере, к которому мы будем отправлять запросы, и он будет присылать нам какие-то ответы на эти запросы. Мы будем говорить ему, допустим, сделай это, сделай то, сделай третье, да, я хочу получить данные такие-то. В общем,

давайте сначала выпишем идею проекта. Я для своей платформы хочу разработать сервис, да, который будет как раз-таки вот как форум на Steck OFlow, где а люди смогут оставлять свои проблемы, прикреплять там, допустим, скриншоты, описывать эту проблему, а другие люди а

смогут эти проблемы все просматривать, а смогут оставлять какие-то реакции, смогут их комментировать, смогут отвечать, да, какой-то давать ответ. на эту проблему, и автор этой проблемы сможет выбрать там правильный ответ, как-то поблагодарить человека, и получится вот такой вот форум примерно.

То есть идея не очень прямо масштабная, но при но при этом а её можно как-то развивать куда-то дальше. При этом этот форум можно вложить в какой-то другой проект. Ну так вот, я буду это реализовывать, и вы сейчас на

практикувидеть, как на практике вы увидите, как это всё проектировать, как это всё составлять, и сами выберете какую-то другую любую идею. В конце этого интенсива, да, я дам задание, где как раз-таки полностью опишу, а весь э ну то, что вам нужно будет сделать, и за

вас придумаю идею, если вы а не сможете придумать её сами. Значит, я рекомендую всё э записывать, то есть вашу идею всю её расписывать где-нибудь. Это может быть просто блокнот, неважно, просто расписывайте. Каким образом это расписывать? Ну, давайте напишем для

сеча заголовок. Это будет, а, форум. То есть это может быть название проекта либо просто краткое его описание. Форум для решения проблем с, мм, значит do net приложениями. Вот, соответственно, вот такое будет у меня проект. И сначала я что делаю? Я выписываю фичи, которые в

нём будут. То есть вообще мм, можно написать как вот вы как пользователь, да, предположим, я Давайте начнём расписывать, я как пользователь хочу иметь возможность публиковать проблему с которой я столкнулся.

Так, давайте исправим грамматику. Столкнулся. А при этом при этом я хочу э описать как можно подробнее мою проблему. А, допустим, указать тег. А, допустим, у меня будут в моей платформе различные теги. Допустим, там EF Core, Ipinet Core, а там, не знаю, Rabit MQ,

чтобы человек мог более подробно указать такие теги и как-то человек другой мог с помощью этих тегов там поискать, допустим, решение уже реальной проблемы.

То есть человек хочет более подробно описать мою проблему, указать тег, прикрепить скриншот. Допустим, он хочет прикрепить какой-то скриншот, там, не знаю, что ещё. А, в принципе, всё, да? Ну, допустим, указать заголовок там и написать Ну ладно, комментарии опустим. Вот это

первая самая такая основная фича. Собственно говоря, пользователь должен иметь возможность, да, опубликовать какую-то проблему. Э для этого, ну, на самом деле, чтобы он мог, пользователь вообще что-то делать, ну, ну, нужны пользователи. То есть, а, в проекте, а, нужны, а, то есть должен быть функционал

для управления пользователями. Пользователями. То есть логично, что почти любой проект должен иметь элементы авторизации и аутентификации. А это очень важно. И вот этот элемент мы его немного рассмотрим, но будем опускать, потому что будет у меня отдельный интенсив по авторизации и

аутентификации. То есть сейчас мы просто подразумеваем, что да, в проекте обязательно должны пользователи бы, которые будут всё это делать. Но когда мы начнём всё это проектировать, мы поймём, что, э, проектирование сервиса с пользователями - это вот отдельная такая

вещь, и без неё можно, а, отлично спроектировать весь основной другой функционал. Собственно говоря, я сейчас вставил те фищи, которые я до этого там примерно вкратце расписал. Давайте их просто прочитаю. Смотрите, их можно оценить, их можно расписывать вот так

вот подробно, но можно расписывать прямо буквально каждую возможность, которая имеет пользователь. Допустим, а вот в проекте должен быть функционал для управления пользователями. А я как пользователь хочу создавать вопросы, чтобы найти решение для моей проблемы, правильно? Ну там создавать проблему,

создавать топик, неважно. Я хочу прикреплять скриншоты для моего вопроса. Я хочу, чтобы другие пользователи могли оставлять разные ответы. Я хочу, чтобы пользователи могли оставлять комментарии под вопросами или ответом, да, или ответами, чтобы уточнить какие-то детали. Я хочу, чтобы пользователи могли

удобно вести дискуссию под вопросами или ответами. И я хочу, чтобы можно было выбрать верный ответ и другому пользователю начисливаться рейтинг.

Допустим, также, допустим, я можно тут дописать, я хочу, чтобы, а, мой ответ, то есть мой вопрос могли оценивать другие пользователи, там вот как накловлять ему какой-то рейтинг. И я хочу иметь удобный поиск, чтобы я как пользователь мог найти готовое решение

для моей проблемы. То есть, если мы посмотрим на вот Overflow, что, в принципе, является неким таким клоном, что мы, что я хочу реализовать, а что мы тут увидим? Вот мы видим какой-то вопрос, какую-то проблему. Мы видим заголовок, какое-то описание. Мы видим

список тегов, чтобы я мог по этому тегу посмотреть там все а-а возможные там вопросы, которые задавали другие пользователи. Я могу воспользоваться поиском удобным. Видите, это полнотекстовый поиск. То есть я хочу иметь полнотекстовый поиск. Мы тоже в дальнейшем посмотрим, как его

реализовывать. Не знаю, будет ли это в этом интенсиве, либо в другом. А, соответственно здесь видите имею возможность, если я перейду в какой-то вопрос, я могу, во-первых, поставить какой-то рейтинг, можно поместить какой-то вопрос закладки, допустим, это можно тоже написать для этого фишу, там

я хочу, а, иметь возможность поместить а вопрос в закладки, да, почему бы и нет.

какой-то вопрос я хочу поместить закладки, чтобы а я мог посмотреть там на будущее какие-то ответы, а так какую-то активность увидеть, в принципе, да, не обязательный функционал. Вот здесь можно прикрепить очень подробно описать проблему, прикрепить скриншоты, всё это тоже мы должны будем

реализовать. Видно, во-первых, кто оставил эту проблему, видно рейтинг у человека, может быть какие-то достижения и видны ответы. Под ответами можно вот здесь оставлять комментарии. То есть вот такой примерно я функционал и хочу видеть. Также пользователь, кто тот, кто

оставил этот вопрос, он может выбрать там правильный ответ. Если мы перейдём, допустим, в А ну здесь вот, да, мы видим зелёненький answer, то есть вот пользователь пометил этот а этот ответ как правильный. То есть вот этот функционал я хочу примерно реализовать,

и его можно дальше развивать. добавить онлайн-чат между пользователями, добавить там для этой всей платформы а какой-то другой функционал, там просмотр каких-то видео, просмотр статей, написание там, ну, работа с поддержкой, там, не знаю, а, публикация вакансий, допустим, по этой вот тематике, для

которой вы пишете этот форум, допустим, а там, ну, опять же, модерация и, в принципе, админка довольно большая здесь может быть. И, ну, любой, в принципе, проект можно вот развивать вшире. А для чего это делать? И смотрите, когда вы

придумываете фичи, сначала не обязательно их прямо усложнять. Сделайте самый минимум. То есть сделайте самый минимум, а потом уже начинайте каждую фичу усложнять. Придумываете какие-то бизнес-правила, придумываете а различные проблемы, которые вы хотите решить. Вот это будет больше работать именно для

второй идеи. Я думаю, что вот следующий интенсив будет по ДД, и там мы уже будем реализовывать идею со сложной бизнес-логикой. То есть это будет либо работа с каким-нибудь бронированием, расписанием, вот что-то такое, где может, ну, где много правил там со

временем, где много правил, а может быть какие-то расчёты. То есть усложнять себе бизнес-логику - это нормально, потому что реальные коммерческие проекты большие, они достаточно сложные. Ну так вот, начнём мы с чего-то такого более-менее простого. И, а, соответственно, сначала

стоит реализовать а приложение MVP, то есть самую вот простую. Почитайте, что такое MVP- это как бы минимальный жизнеспособный продукт, самую простую версию этого приложения. Вот. Но мы сразу в этом интенсиве начнём, а, планировать и строить архитектуру этого приложения для дальнейшего

масштабирования и развития. Мы будем на это всё опираться, чтобы можно было легко из какой-то более маленькой идеей взять и вырасти во что-то большое, либо взять и придумать новый функционал на ходу и легко его реализовывать. и ваш проект будет очень гибким и приятным,

да, для разработки. А, соответственно, вот наша цель. Допустим, выписали вот мы эти фичи. Что дальше? Дальше я предлагаю вам спроектировать предметную область.

То есть очень важно дальше спроектировать предметную область а вашего проекта. Что такое предметная область? Соответственно, это основные какие-то единицы там, сущности, с которыми вы будете работать. Что я подразумеваю? Вот что есть в моём проекте, какие тут есть сущности. Легко

заметить, что, во-первых, есть usер какой-то пользователь, есть какой-то question, который, а, этот пользователь мог может оставить. Есть ответ, это answer. Вот просто берёте и вот таким образом выписываете все эти моменты просто себе в столбик вот так вот на

какую-то доску либо опять же в блокноте. А есть комментарий, есть рейтинг у пользователя, то есть все возможные как бы сущности, которые только могут быть.

Там есть рейтинг, комментарии, вопрос. Что там ещё? Так, есть ещё теги. Есть тег у нас, он может быть у всего подряд, да? И есть у нас ещё любимые там favorite. Ну это favorite question.

Вот так вот. Это, чтобы пользователь мог, соответственно, какие-то помечать вопросы, там, сохранить их куда-то, либо их их можно назвать не favorite, а question. Вот сразу делаем всё на английском, чтобы можно было, а, ну, легко потом это как бы в код ваш ваш

проект это всё там реализовать. Соответственно, вот мы выписали все основные сущности. У вас это могут быть компьютерные слоты, а какие-то билеты, время для бронирования, а пользователи, там время, ну, статистика пользователя, а какие ещё идеи? Там денежные средства на вашем счету. То есть наже нужно вот

выписать все возможные сущности для вашего проекта. А дальше, мм, что нужно сделать дальше? Дальше нужно установить какие-то связи между всеми этими сущностями и разделить их на модули. Вот мы затронем сейчас очень такую важную вещь, как Cahesion и калин. Для чего это

нужно? Зачем что-то вообще разделять на модули, на разные части в вашем приложении? И потихоньку, так как унёмся в монолит, модульный монолит и в микросервисы, чтобы понять, ну, для чего нам всё делить на какие-то модули. В общем, как нам это делать? Вот есть, а

давайте по какому принципу мы делим что-то на модули? Вот я как разработчик с опытом, да, вижу, есть юзер. И я понимаю, что юзер, да, и управление всеми пользователями, работа с пользователем - это отдельный модуль сразу, да, без, так сказать, каких-то

вопросов мы выносим это в отдельный модуль. Что значит вынести в отдельный модуль? Это значит, что вынести либо это в отдельный сервис, в отдельный микросервис, в отдельный проект, в отдельную папку. В общем, модуль - это как бы единица, а, каких-то там сущностей, каких-то

операций, каких-то возможных действий, которые очень тесно друг с другом связаны. То есть, допустим, я могу вынести юзера в отдельный модуль, потому что все операции, которые будут у меня происходить с этим пользователем, там, допустим, регистрация этого пользователя, а это может быть

там логин этого пользователя, там его редактирование какого-то профиля, ведения статистики с пользователем и рабо ну управление там редактирование удаление получения пользователей. Всё это будет относиться к этому модулю, потому что это, ну, никак не должно пересекаться со всем остальным. Ну, как же так? Мы можем

сказать, вот у нас пользователь будет иметь вопросы, но он будет он может создавать вопросы. То есть мы можем, а, установить вот такую связь. То есть мы сейчас не говорим там про базу данных, там, отношения между сущностями. Мы вот

говорим именно как про реальный мир. Пользователь может оставлять вопросы, тогда что ж получается? Нам модуль надо растягивать каким-то образом? Нет, смотрите, а предметная область, мы должны выделить в нашей предметной области вот такие вот м как бы разделить это всё на разные модули. То есть модуль

вопросов будет подразумевать то, что он будет отдельный тоже, потому что, а, там создать вопрос, выбрать правильный ответ. И вот когда мы создаём вопрос, мы сразу подразумеваем ответы, что другие пользователи смогут оставлять ответы.

Соответственно, у нас такая вот связь есть между вопросом и ответом, и она достаточно сильная. А, то есть без, ну, ответ не может быть без вопроса.

Правильно? Правильно. Поэтому мы берём и устанавливаем вот такую связь. Ну, можно сказать, что, ну, стойте, подождите. А как бы вопрос не может быть без пользователя. Почему мы это делим на разные модули? А потому что это разные предметной области. И потому что мы,

когда вот так вот делаем, мы разделяем как бы ответственность. Смотрите, вот этот модуль, он за что ответственен? За что он несёт ответственность? За управление пользователями, за регистрацию, за там его безопасность, за за его роли. То есть у пользователя ещё

там можно создать такую вот сущность, роль за его права, да, которые он имеет на этой платформе, за то, кто он такой вообще, какой у него там рейтинг и так далее. Вот вот этот модуль будет нести ответственность за вот эту всю штуку.

Всё, что относится э-э с пользователями с точки зрения какой-то вообще любой даже платформы. У любой платформы будет модули пользователей, который определяет его права, какие-то ограничения, его возможности, его почту, его там контактные данные и так далее. А вот этот модуль, он будет отвечать чисто за

вопросы там и ответы. Возможно, сюда ещё что-то добавится. Да, пользователь может создать вопрос, но какая Ну, нам нужно установить связь, что у вопроса какой-то какой-то пользователь оставил этот вопрос. И эту связь мы устанавливаем через ID. То есть мы

берём, и у нас вот такая вот будет связь в виде user ID. А почему по ID? Ну, мы тут приближаемся немного к проектированию именно к такому более конкретному, там, к базе данных, там, к таблицам, отношению между сущностями. А,

ну мы, короче, хотим у просто иметь ссылку на этого пользователя. Вот сказать: "Да, вот этот вопрос задал вот этот пользователь. И вот эту ссылку в системах, в приложениях, да, в программировании принято держать в виде ID". То есть у каждой такой сущности

есть какой-то идентификатор, то есть уникальный ID. И вот между связь между вопросами пользователей будет просто в виде ID, потому что смотрите, а когда я говорю: "Выносим вот это в модуль отдельный", это значит, что а в этом модуле у нас будет там работа с базой

данных, работа с там авторизацией, аутентификацией для этого пользователя, работа там с брокером сообщений, может каким-то, какие-то фичивателя. То есть кода в этом модуле будет довольно много.

Если мы возьмём и объединим всё это в один модуль, там будем всё это вот так смешивать, то получится так, что у нас всё смешается в кашу. То есть есть такой принцип, как вот сейчас мы перейдём к теме Casation, но давайте сначала

затронем такой более базовый принцип, это single responsibility принцип. Самый основной, можно сказать, принцип в проектировании, программирования OP - это принцип единой ответственности. У нас класс, метод, вообще всё, что угодно, оно должно отвечать, там нести какую-то ограниченную область действия. То есть

оно должно отвечать отвечать за что-то одно. И это применимо ко всем слоям разработки. Это применимо и к архитектуре вообще целого вашего приложения, к архитектуре там именно инфраструктурной, там микросервисной, там монолитной. Это применимо к классам, как вы их выстраиваете. применимо к

таблицам в базе данных, применимо к, а методам даже, которые вы пишете. У вас один метод решает какую-то одну задачу.

Один класс работает с какой-то одной областью, решает одну задачу. Один модуль, вот модуль users, его можно даже вот тут назвать users там или accounts, неважно. Он решает какую-то задачу с пользователями.

Дальше вот этот модуль, давайте я ему дам название CHS. Он решает задачу с вопросами и ответами.

И важно вот когда вы всё это проектируете, разделить всё это на модули. Я сейчас не говорю выбрать там, что это будет отдельный микросервис, хотя может быть. Я не говорю, что это будет отдельный проект, хотя тоже может быть. Я говорю просто взять и логически

вынести это в отдельную какую-то вот в отдельную область и связь установить просто по айдишникам. То есть, да, мы тут работаем вот как бы близко к базе данных уже как-то перешли, но так будет проще сначала думать. Вот у нас кто

оставил вопрос? Какой-то пользователь. А как мы можем обозначить, какой это пользователь? Просто user ID. И вот в этой источности будет просто храниться значение вот этого идентификатора, что он оставил, значит, этот вопрос. То же самое с ответом, да? Какой пользователь

оставил ответ? Тоже usеer ID. Мы можем тут тоже нарисовать стрелочку. То есть у нас вообще, аа, вот таких связей с usеer ID будет довольно много. Это нормально.

У нас в принципе всё делают пользователи. И в любых системах у нас очень много встречается usеer ID, и это абсолютно нормально. Так вот, а давайте дальше продолжим всё это проектировать и разделять на такие вот подгрупки. И зачем я вас вообще, ну, так

сказать, тренирую вот этого вот этому вот модульному мышлению? Для чего я это делаю? Потому что есть очень важный принцип в программировании и в проектировании. Это low cing high cohesion. Вообще, что это значит, для чего это нужно, почему на

это нужно обязательно ориентироваться. Для начала давайте простым языком. А для чего мы всё разносим по по модулям и по каким-то частям? Во-первых, а так будет для мозга и вообще для человека проще это всё структурировать. Вот есть там у

меня какая-то система, какой-то кусок кода, который отвечает чисто за пользователей. Вот есть система, которая отвечает за вопросы и ответы. Там есть система, которая отвечает за комментарии. Есть система, которая отвечает за рейтинг там или за теги. Мы сейчас это всё, так сказать,

продолжим расписывать. И, э, когда вы всё делаете по частям, будет намного проще управлять всем проектом, потому что коммерческие проекты, они очень большие, часто они разрастаются. Если там, э, разработчики не применяют вот эти принципы, о которых мы сейчас поговорим, то всё это превращается в

огромную кашу. Всё это становится суперсильно сплетено, переплетено и очень сложно управлять кодом и понимать, что вообще происходит. Поэтому давайте разберём следующие принципы. Значит, важнее, вот я тут немножко расписал, давайте это обсудим. А каплинг и кожен, как это переводится на русский. В общем,

это важнейшие принципы, чтобы делать код понятным. тестируем им и переиспользуем им. Кохен - это сцепление. Вообще чёткого прямо перевода нет. А по-русски очень сложно понять там. И вот часто переводит как- это сцепление, а вот кауплинг как связанности. Вот что-то

похожее. Но часто просто говорят, вот есть коплинг, есть кохion. Вот главное запомнить, вот у меня даже часто я путаю тамхion и каплинг, что оно значит. Ну короче, давайте вот попробуем это запомнить. Кохен, то есть цепление. Что он делает?

То есть как бы сцепление между различными объектами, единицами вашего кода или приложения, он измеряет, насколько компоненты или или элементы вашего там кода приложения класса метода сервиса внутри одного модуля связаны друг с другом и работают для выполнения одной задачи. Вот что это значит, когда

у вас, ну, то есть, во-первых, это некая степень, а, которая измеряет что-то. То есть эта степень, она может быть высокой или низкой. А, то есть это как некий параметр, а, то есть высокая Cheesion, когда у вас вот этот параметр Кохезии,

ой, сцепления он высокий, то у вас какой-то модуль вашего приложения, он сосредоточен на выполнении одной как конкретной задачи. Вот, предположим, ну, давайте я дочитаю. Все элементы модуля, а, тесно связаны по смыслу, и это упрощает понимание, тестирование и повторное использование. А вот когда у

вас низкохн, то модуль выполняет несколько разных несвязанных задач. Это делает его сложным для понимания изменения. О чём речь? Тут ниже картинка, сейчас её приведём. Вот я вынес users в, э, отдельный модуль. Это может быть просто какой-то users сервис,

отдельный класс, который имеет все операции с пользователем. Причём вот это вот cation и cllлиing, это применимо абсолютно ко всем слоям и ко всем, так сказать, промежуткам вашего проектирования. Это может, вы можете это применять, когда вы проектируете микросервисы, когда вы проектируете

архитектуру вашего приложения, когда вы проектируете слои в вашем приложении, когда вы проектируете классы или методы.

Смотрите, с чего я добился, что я вынес ютерс в отдельный модуль. Как мы читали из определения, а когда у нас все элементы, которые работают над чем-то одним, над какой-то одной задачей, они все тесно соединены и находятся в одном

модуле, то тогда у нас появляется высокая кохен, что хорошо, мы должны стремиться к высокой кохен. Но если бы у нас был бы вот этот один модуль вот таким, допустим, давайте я сейчас попробую вот так вот сделать один модуль. И сюда бы мы поместили ещё и

там, не знаю, теги, комментарии, рейтинг, то у нас получится так, что у нас внутри одного модуля содержится много единиц чего-то, то есть много единиц разных элементов, которые работают над разными вещами. Теги работают над одним, комментарии вообще- это другое, вопросы - это третье. И

получается, что у нас низкая кохен, то есть у нас низкое сцепление. У нас, а, как бы у нас много элементов разных, которые находятся в одном, они тесно связаны. И когда вы что-то одно меняете, оно меняется сразу другое, третье, нужно

следить за пятым. Поэтому, а, когда вы разделяете всё вот какие-то, когда вы выносите, в общем, в отдельный модуль, там, класс, сервис, когда вы выносите вот что-то одно, то есть вы находите в вашем а приложении допустим элементы которые тесно связаны. Вот в моём случае это и

answer. Почему? Потому что безна ну никак не может быть answer? Ну никак. То есть ответ он подразует, что есть вопрос, они очень связаны. И все операции там оставить вопрос для чего?

Для ответа. Оставить вопрос: "А по какой теме? По ответу". Ну по этому, то есть оставить ответ по этой по этому вопросу.

Это очень связано. Я это выношу в отдельный модуль. И таким образом я достигаю высокой кохен. То есть у меня вот высокая связь между вот похожими элементами. Смотрите, давайте дальше попробуем это всё дело проектировать. А сейчас мы рассмотрим, что такое каплинг. Вот теги. К чему

могут относиться к теги? Вообще теги могут быть у вопросов, правильно? Как бы, да, теги в данном случае можно поместить сюда, вот в этот модуль мы взяли и вот элемент, который тесто связаны, поместили в один модуль. Но, но если мы работаем и мыслим на какое-то

масштабирование, будущее нашего проекта, то можно сказать, что теги, а будут ли они только у кеншнов, потому что теги в нашей какой-то будущей платформе могут быть у много чего. Мой реальный пример, у меня сейчас вот образовательная, мы делаем образовательную платформу, там у

нас будут уроки, задачи, какие-то топики, может быть, статьи. И у всего этого может быть тег, там тег, тег C#P, тег там, не знаю, проблемы там с базой данных. И а вот эта система тегов, она может относиться к очень разным

сущностям, и все хотят иметь теги. И поэтому на будущее, если вы понимаете, что ваш проект будет расширяться, то тут нужно понять, да, теги у вас будут только у вопросов или теги могут быть вообще у много чего. Я сделаю так, что

теги могут быть у много чего ещё в будущем. Поэтому я возьму и вынесу теги просто в отдельный модуль. То есть я говорю, у меня вот отдельный модуль просто тег. У меня модуль состоит из одной сущности. Это нормально. Это это

абсолютно нормально. Тут нет, ну ничего такого. Давайте я это чуть ниже опущу. Дальше комментарии.

Опять же, если мы подразумеваем, что наш проект заканчивается только на вопросах и ответах, то комментарии могут быть только у них. Мы их суём в этот модуль.

Если же мы подразумеваем, что в будущем комментарии могут появиться под, а, статьями, другими постами, под видео, под, не знаю, под профилем пользователей, это уже сюда надо.

Поэтому мы берём и комментарии тоже выделяем в отдельный модуль. То есть давайте я это вот так напишу коммент.

Коммент. Так, это будет comс. Мы выделяем это дело всё в отдельным модуле, потому что он, вот этот модуль, он может в будущем взаимодействовать с очень разными компонентами в нашей системе.

Поэтому будет грамотным шагом вынести это тоже в отдельный модуль. Давайте это уменьшу. Всё, всю эту доску я тоже прикреплю обязательно к этому интенситиву. можете на сможете на неё зайти, потыкать. Дальше рейтинг.

Рейтинг, да, мы пока вот выделили основные сущности. Это могут быть не все сущности, это просто самый-самый базовый функционал, который может быть. Куда нам поместить рейтинг? Что вообще такое рейтинг? Рейтинг может быть у, у вопроса, рейтинг может быть у

пользователя, рейтинг может быть у комментария и, может быть, даже у тега, не знаю. Но смотрите, рейтинг - это просто числовое значение. 1 2 там -100 п 100. И в целом рейтинг можно отнести а к разным тоже модулям в нашей системе, да,

он может быть отдельный у вопроса и там у пользователя. И вот смотрите, здесь идёт важ важный такой элемент. Мы говорим, что рейтинг - это как отдельная такая сущность. Там под неё нужно делать отдельную таблицу в базе в базе данных. Либо мы говорим, что

рейтинг - это просто значение, которое может быть либо у пользователя, либо у вопроса. Вот это как, знаете, у пользователя может же быть имя. Это просто значе имя пользователя, там заголовок какой-то там у вопроса. Мы же не выносим заголовок вопроса в отдельную

сущность, правильно? Это просто какой-то элемент значения. Ну, value object, если говорить там, если к ddd обращаться, это будет value object. А про ДД как раз-таки мы поговорим в следующем интенсиве, скорее всего. Соответственно, смотрите, а когда мы говорим про

рейтинг, не стоит вообще, мне кажется, вот поначалу, может быть, мы поймём, что стоит, но пока, мне кажется, это вообще не стоит выносить как отдельную сущность, а просто подразумевать, что это как будет свойство. То есть свойство у вопроса, у него будет просто числовое

значение рейтинга. И там, ну, правда, у нас, когда там другой пользователь будет тыкать на там изменение рейтинга у этого вопроса, это должно будет повлиять как-то на юзера. Ну, это всё, всё довольно просто, да? То есть, короче, рейтинг нам стоит вообще отсюда убрать,

потому что это будет именно как свойство. Свойство юзера, свойство вопроса, свойство комментария. Всё. Так, saved questions. А куда нам можно поместить save questions, чтобы пользователь мог добавлять там свои, ну, сохранять вопросы для будущего просмотра? Как бы логично, что раз

пользователь это может делать, да, Saveed questions можно поместить сюда к пользователям. Ну, сюда это помещать не очень, потому что тут мы подразем, что это как бы общие вопросы, там пользователь задал вопрос, а как бы в модуль saved questions как-то не очень.

То есть у юзера, у модельки юзера можно просто добавить, соответственно, вот questions. Вот здесь вот ещё один вот ещё одну вот эту сущность. И это может быть просто список айдишников. Вот сейчас мы более подробно поговорим. Мет потом это перепроектируем

как-то. То есть поначалу это выглядит нормально, если это сделать так. А, конечно, можно вынести вообще в отдельный это модуль, а, и сказать, что там, не знаю, у нас будет ещё один юзер.

То есть на самом деле может быть такое, что у нас буде может быть два этих модуля. И здесь может быть юзер, и здесь юзер. Просто они будут отвечать немного за другое. Это юзер, который просто нужен для авторизации в системе,

а это юзер, который может просто оставлять вопросы и ответы, допустим. Но в данном случае нам, скорее всего, этого не нужно делать. То есть мы будем работать отдельно как с вопросами и отдельно как с ответами. Хотя тоже, знаете, тут спорный момент, потому что

вот тоже как, ну, я я вот хочу в этом интенсиве рассмотреть как можно больше различных вариантов. Если мы сюда, то есть добавим юзера ещё одного, то есть да, такое может быть. У нас в одном проекте могут быть, а такие вот моменты

одинаковые, то есть они могут звучать там юзер тут, юзер там, но при этом отвечать за разные. Смотрите, вот этот юзер будет отвечать только за как бы функционал по вопросам и ответам. То есть юзер, он может иметь вопрос и может

задать, э, задать какой-то ответ. И стоит ли здесь добавлять юзер? Вот, мне кажется, не стоит, а потому что это только усложнит работу, там синхронизацию между этим юзером и этим юзером. Это нужно будет продумывать.

Поэтому давайте это уберём. То есть я скажу потом в какой, ну, как это можно потом как-то применить к этому всему и упростить. Но пока давайте сделаем это вот таким образом просто. Ну так вот.

Saved questions можно, в принципе, оставить здесь, да, что-то тут лишнее это добавилось. То есть у нас, предположим, что у юзера будут просто там список айдишников, его там вопросов, которые он хочет сохранить. Предположим, потом в будущем у нас м пользователь

сможет сохранять ещё какую-то информацию, создавать какие-то плейлисты, а, создавать какие-то свои заметки. И это можно будет вынести вообще в другой модуль, где пользователь, да, уже вот тут пользователь сможет создать, допустим, какой-то там, не знаю, плейлист, там люби любимых видео плейлист или там, ну,

какие-то сохранённые данные. И уже вот тогда мы сможем Save Questions вынести это сюда. Вот тогда в отдельный модуль.

Но когда у нас просто одна сущность, там нет смысла прямо пилить целый отдельный модуль для того, чтобы пользователь мог просто хранить какие-то любимые там свои ответы. Можно это помести в этот в этот модуль. Сильно плохо от этого не будет.

Но опять же, если нам добавится ещё что-то сюда, это уже будет как бы, мне кажется, нарушать. То есть нужно тоже знать грань, когда можно добавить что-то в один модуль, а когда лучше не стоит.

Поэтому когда вот что-то одно, там любимый вопрос, о'кей. когда ещё там возможность сохранения целого плейлиста, добавления вы избранное, добавление там ещё чего-то. То есть тогда уже, может быть, стоит создать вообще целый отдельный модуль, именно избранное fa reads а модуль, да, где пользователь

сможет добавлять что-то в избранное. То есть также будет пользователь, какая-то сущность, ну, чтобы олицетворять тут просто ID этого пользователя. И, допустим, там сохранённый вопрос, сохранённый ответ, сохранённая фотография, просто лайкнутое что-то там, это видео и так далее. И всё это можно

сюда будет поместить. Вот. А, ну что ж, примерно вот так мы это разбили. И сейчас давайте поговорим о том, что такое кауплинг. Каулинг, давайте сначала прочитаем из определения. Это, ну, переводится как связанность. То есть кохion - это сцепление, а каплинг - это

связанность. То есть каплинг - это тоже степень, да, она измеряет, ну, либо каплинг измеряет степень зависимости зависимости между разными модулями или компонентами системы. Слабоя каплинг, то к чему мы стремимся, а, это когда модули минимально зависят друг от друга и

изменение и изменения одного модуля практически не требует изменений в других. Это повышает гибкость системы и упрощает её поддержку. А сильная кауплинг - это когда, ну, это плохо, это когда модули, они сильно друг от друга зависят. Изменения в одном модуле могут

требовать изменения в других модулей. Это очень усложняет внесение изменений и уменьшает гибкость системы. И вот в конце я написал, да, что мы хотим стремиться к именно высокому сцеплению и низкой связанности. То есть мы стремимся к высокому и к низкой каплиing. А если

говорить вот про пример каплинг, да, что значит а степень зависимостями между модулями? Вот если говорить про зависимость, опять же это применимо к нескольким слоям нашего приложения. Это принимо к инфраструктурной архитектуры.

Ну, я это называют там, когда вы проектируете там один микросервис, второй, третий, как они будут связаны друг перед другом, либо а это применимо как классы друг от друга зависит. Вот в данном случае мы говорим как бы больше про предметную область, наверное, ну и

при этом опираясь на тоже взаимосвязи между этими модулями. Вот смотрите, какая у нас тут связанность между модулями и есть ли она вообще. А на самом деле она есть. То есть смотрите, а как она проявляется? Вопрос. Кто может создать вопрос? Вопрос может создать

юзер. А у юзера есть, ну, мы опять же сказали, что связь у нас между модулями, она будет проявляться в этом вот уникальном идентификаторе, то есть в User ID. Является ли такая связанность сильной или слабой? Я вам отвечу. Такая

связанность является слабой. И это хорошо. Это то, к чему стремимся. Почему она является слабой? Вот сейчас мы поговорим больше про ООП. Вот представьте, у нас бы здесь связь была бы не user ID, а, допустим, модель usеer. Ну вот прямо прямая ссылка в

cшарпе, прямо класс usер мы бы хранили. Тогда мы бы имели доступ к юзеру, и мы бы могли как-то этого юзера изменить, как-то бы, ну, что-то с ним сделать. И при этом, если бы внутри юзера бы что-то поменялось, то это бы отразилось на наш

код. Но если у нас единственная связь - это просто usеer ID, то нам вообще всё равно, что поменяется в этой модели, что поменяется в этом модуле, поменяется ли здесь логика, уберётся ли оттуда save questions или ещё что-то. У нас просто

связь есть в виде user ID. Типа мы просто говорим: "Да, у нас вот вопрос оставил вот этот, на вообще всё равно, что там внутри юзера происходит.

Главное, что есть usеer ID". То же самое. Смотрите, вот теги. А связь с тегами какая? А у там квешена могут быть теги. То есть мы говорим, у кшна могут быть теги, и это будет тег. А, ну и в принципе всё. И там, ну,

про рентинг мы сказали, это просто свойство. Вот у нас связь между кеншнами и тегами тоже тег. Изменим ли мы описание? Вот смотрите, что будет, если мы изменим описание тега. Ничего. Если бы мы здесь хранили целую сущность, то и

как-то бы с ней, возможно, взаимодействовали, типа через вопрос, изменить там название тега, то это бы вызвало проблемы. А сейчас мы просто говорим, ссылаемся на этот тег по ID. И поэтому у нас слабая связанность между модулями. То есть если мы меняем

какой-то один модуль на другой модуль, это никак не влияет. То же самое с комментариями. Смотрите, комментарии можно оставлять либо под ответ, либо под question. Давайте вот так вот. То есть здесь у нас связь, коммент, ID, а комментарии оставляет какой-то

пользователь. То есть у нас здесь ещё есть связь вот такая вот. User ID. Конечно, если рисовать вот эти связи, может казаться, что всё как-то сильно связано. Но на самом деле, когда у нас вот такая связь - это просто

айтишник, это это нормально. То есть когда у нас вот такая связь, давайте даже пометим, то есть вот эти стрелочки, я не знаю, я нарисую голубыми. Вот внутри модулей у нас сильная связанность. И это хорошо. Поэтому у нас, когда внутри модулей вот эта вот

сильная связанность голубая, это хорошо, потому что опять же тут у нас высокий кохен, да, помним, у нас а вот эти элементы они все логически связаны. Но а когда у нас уже связанность между разными модулями, то она тут такая беленькая. Я даже могу

сделать вот так вот нарисовать штрих-код такой вот сделать штрих, потому что такая связь, она слабая, да? И вот здесь тоже связь слабая, потому что просто это ID. То есть мы таким образом достигли, что у нас внутри модулей высокое

сцепление, таких связанных очень сущностей. А поэтому это хорошо, у нас высокий кохеion и при этом у нас низкий кауплинг, низкая связанность, да, потому что у нас разные модули просто по айтишнику друг с другом взаимодействуют.

И изменение в одном модуле никак не влияет на другой. Смотрите, это ещё применимо к другим уровням архитектуры.

Сейчас мы это просто как бы проектируем нашу предметную область, но м это может быть проектирование разных микросервисов, это может быть проектирование слоёв в каком-то проекте вот по чистой архитектуре. Там есть разные слои, и они как-то друг с другом

связаны. И всё это вот сейчас мы будем разбирать. Значит, что делать дальше? Смотрите, вот ещё раз обсудим шаги. То есть первый шаг, первый шаг номер один.

Давайте я его здесь вот так вот циферкой напишу. А как разработать, спроективировать пример проекта какой-то? Это расписать фичи. Давайте функционал, расписать функционал проекта, потому что это важно, чтобы вы могли на что-то опираться после того, как расписали функционал. А вы вот на

эти вот фичи можете как-то опираться. И что делать дальше? Дальше вам нужно после этого, так вот, вынесем это сюда, чтобы было красиво, вам нужно спроектировать предметную область. А проектирование предметной области - это как раз-таки вот то, что я сейчас и делал. Это

выписывание основных каких-то сущностей либо компонентов в вашей системе и установка между ними связей. и разделение это всё на какие-то модули отдельные. А, возможно, у вас не будет сразу это получаться делать хорошо. То есть, скорее всего, да, без опыта у вас

это не очень будет хорошо получаться. Ничего страшного. Во-первых, вы можете всё отрефакторить в будущем. Во-вторых, а если вы будете хотя бы стараться мыслить вот так же, как я, то таким образом вы изначально уже построите более-менее архитектуру, дальше что-то

от неё открепите. Главное вот разделить всё на более-менее вот такие понятные модули. Ну или хотя бы определить конкретные сущности, а между этими всеми штуками.