все верно, вы сказали: что бы мне чтото найти я захожу на страницу и кликаю по нужной зависимости
Ну если у вас проблемы с навигацией и вы не знаете где лежит компонент и не знаете его названия, то да, по сути это самый быстрый и эффективный способ. Но вы всегда можете использовать альтернативный метод - погадать на кофейной гуще, вызвать пиковую даму и поговорить с "доменами", они вам скажут где искать. Но этот вариант будет несколько дольше по времени.
Согласно таким рассуждениям - классическое разбиение избыточно
А мне не избыточно, мне нормально)
так как в не пользуетесь навигацией по папке кроме как найти нужную страницу
Конечно, и не пользуюсь IDE и не пользуюсь компьютером тоже.
итого, у меня в шаред лежит кит на 200 файлов с разбитием по категориям. и строго понятно, что эти 200 и предполагают их переиспользование.
И у меня, только в src/components
у вас в компонентс лежит 2200 компонентов. половина из которых имеет смысл только в контексте других компонентов.
Нет. Все они распределены и сгруппированы.
С ростом проекта - когда станет понятно, что есть несколько страниц использующие одни и те же компоненты, то будет желание либо вынести эти компоненты в /components, либо создать домен, в котором будут лежать и эти страницы и компоненты.
Судя по вам вы предпочтете первое, и я показал на примере к чему это приводит.
К чему? К фейковым мыслям что в src/components на одном уровне вложенности будет лежать 2200 компонентов из ваших фантазий? :D
Я не создаю "домены" и не вызываю пиковую даму и т.п. Я делаю группировку исходя из логики и здравого смысла.
воот, а говорите правил и ограничений нет. Ведь на ревью вы запретите человеку класть страницы в хуки.
Настолько банальные до абсурда вещи опускаются когда речь идёт о ограничениях. Разумеется никто не будет класть страницу в хуки или utils.
Так зачем вы тратите в разы больше времени на пооддержание этой структуры, и решаете проблемы которых нет?
Я не трачу на нее время. Мне НЕ надо думать а вот это, это что, "демон" или widget или feature или entity или shared или пиковая дама или /ui/ui/ui/ui/ui .. А вот точно ли это entity? а может все таки feature. Ну ладно, а потом бац и на код ревью fsd фанатик говорит, а не, это вообще widget и ещё ты не достаточно много /ui/ui/ui/ui/uiнасоздавал, нужно больше.
У меня всё элементарно: Страницы сразу идут в src/pages Общие компоненты сразу идут в src/components Лейауты сразу идут в src/layouts Вложенные компоненты сразу идут в ./components
Тут 0 дилем, 0 спорных моментов, 0 недопониманий. Поэтому умножаем на коэффициент 0 и получаем 0 extra time на ведение и поддержание архитектуры.
Зачем на его поддержку вы тратите в РАЗЫ больше времени, и героически превозмогаете проблемы которых нет?
Я не знаю о чем вы, у меня нет проблем, и не было) Я хоть говорил что у меня есть какие-то проблемы?) Я ничего не превозмогаю, потому что нет объекта превозмогания) У меня же архитектура здорового человека используется на проектах)
Так почему же мы не можем все сложить в общую папку (кроме страниц), а вдруг должны делать какое-то разбиение
Складывайте если хотите)
(использующее вашу логику).
У меня нет такой логики) Я сто раз показывал скриншот как я группирую файлы и папки) Ваши фантазии не знаю)
Ведь вы сами сказали, что разбиение не важно, так как оно не решает никаких проблем.
Моего разбиения хватает выше крыше) А всё сверх этого уже избыточно и ничего не решает, а только создает) См. скриншот которой я сто раз скидывал.
Так зачем оно вам нужно (ваше логичное и правильное разбиение), если вы все равно через ctr + клик навигируете?
Потому что в классике оно сюрприз логическое и интуитивное. А это мы одобряем и всю жизнь одобряли.
Остальные 170 общих компонентов которые все части системы используют значит выкинули в мусору, умно. (Ниже выясняется что оказывается это были не общие компоненты, а вообще все компоненты в проекте в вашем примере со списком компонентов)
я вас за язык не тянул. Так выходит оно неверное? так как нет у меня не будет ни в одной папке проекта 30 файлов. Так как у нас получилось из проекта где всего 200 компонентов, вдруг 200 общих компонентов?
Так бы и сказали, что это не общие компоненты которые принято держать в папке src/components , а вообще все компоненты в проекте. Они буду распределены по папкам src/components/.., src/pages/.., src/pages/{pageName}/components/.., src/layouts/.. Вот прям как тут, давным давно показано:
вот это поворот. Зачем же вы это делаете? Ведь нет никаких проблем и вы можете спойно прокликать позависомстям? Зачем вы тратите в РАЗЫ больше времни и поддерживаете какую-то структуру. Это же неудобно.
Посмотрите дату где впервые скриншот появился. Какой "вот это" поворот? Это то, как я с 2017 года группирую файлы и папки.
очередной обман. давай страницу положим в хуки. почему нет-то? или кто это может запретить?
Ну если лично вы хотите, кладите, ваш проект, ваши правила) Я страницы кладу в pages) Самое название pages наверное о чем-то говорит да?)
Ну вы утрируете сильно и драматизируете) У вас просто фанатичное помешательство на FSD и папках, а я группирую все так, как диктует здравый смысл и логика) А не ограничения и правила которые силой мне решил навязать какой-то сайтик где хранится описание Freaky Sliced Design.
нет не будет. Вы не понимаете как пользоваться инструментом и опять пишите глословные утверждения.
Т.е. в shared не место для общих компонентах приложения которые используются разными его частями сколько угодно раз?) Интересненько
вот у нас есть конкретный пример по ссылке. Я его расскладываю по ддд, и вы пытаетесь показать, где у меня хоть на одном уровне наберется хотя бы 30 файлов.
Да не вопрос, я в этом не сомневаюсь. Но это не дает профита. В классике их тоже можно легко сгруппировать по папкам. Более того, я их группирую по определённым признакам и у меня нет простыни из 200 компонентов. Не знаю откуда вы это взяли вообще.
Если у меня получается - вы признаете свою ошибку. Если вы не признаете - то мы понимаем что вы раз за разом используете обман и не умеете принимать противоречащие вам факты.
У вас опять все строится вокруг группировки по папкам, в классике это делать легко и непринужденно, более того никаких ограничений в этом нет.
Если бы я говорил что классика запрещает группировки и нужно только все папки внутрь src/ засовывать, то да, конечно я бы безоговорочно проиграл. Но в классике то есть группировка и она ничего не запрещает, какое тут может быть поражение? Хоть группируй сильнее, хочешь слабее, вообще ноу проблемос.
У вас в папке компоненты 200 строк. и так же в hooks.
Дык пожалуйста, пускай себе там лежат эти 200 общих компонентов в папке src/components, и даже без группировок. Вот такой у нас проект, много в нем общих компонентов. Что от этого меняется? Алгоритм нахождения нужного компонента/хука/чего угодно не зная названия неизменен, я описывал его выше. И это не имеет отношения к тому, классика или нет. Если в проекте 200 общих компонентов, то они просто будут лежать в папке shared если используется fsd.
Вы откровенно врете картинкой.
И после этого смеете что-то говорить про манипуляции?
Вы писали что по "моей" логике, ничего в папки складывать не надо, можно просто на плоском уровне все пихать и всё. А я просто показал(сотый раз) что я так не делаю и у меня есть папки под конкретные нужны проекта.
У вас так же откровенная манипуляция про скорость разработки в фсд. Стоимость возрастает в разы? То есть вы 1 час пишите компонент, а потом 3 выбираете куда его сложить в фсд? Ухх в таком случае вам нельзя фсд пользоваться.
Во время создания думаете куда что положить, вариантов то масса (features, enities, widgets, shared, pages) боретесь с ограничениями и подстраиваетесь под них, плодите лишние папки просто ради папок, потому что так заведено в fsd. Это всё в довесок даёт минус мораль, что тоже сильно снижает производительность.
Во время условных правок вы во первых ищете все по кусочками разбросанными по всевозможным features, enities, widgets, shared, pages, по бесконечным /ui/ui/ui/ui/ui/ui , опять беретесь с ограничениями, подстраиваетесь под жесткие правила. Этот сценарий всё так же в довесок даёт минус мораль, что тоже сильно снижает производительность.
И это только то, что прям на поверхности, без дополнительных нюансиков в виде код ревью у фанатика fsd, которое проходить каждый раз это целое испытание.
И вот по совокупности всего это bull shit'a да, скорость разработки серьезно страдает и да, минус мораль вносит огромную лепту в это, а не только сам факт убогости fsd.
Это довольно забавно как вы не понимаете, что такое допен, не хотите слушать, что это и как должно работать, и поэтому считаете, что это не работает.
Т.е. вы тот самый проповедник? Вы там самая истина в последней инстанции? Получается вы правы, я не прав, просто потому что вы так решили, лихо однако)
Вообще бывают разные варианты. Но не суть - микрофронты часто используют как разбиение по доменам. И даже вы упоминали их в этом контексте. А теперь вдруг доменов нет.
"Домены" это лишь абстракция и иллюзия. А микрофронты разбивают по логическим частям приложения и они не независимы друг от друга, просто разделены но не независимы. Это для меня в порядке вещей, потому что так и должно быть. И не вижу проблем при использовании классики в данном случае.
так же как вы разделяете, что должно лежать в стейте, а что не должно. Использую логику.
Тогда бы вы не использовали FSD.
Если вот этот код имеет смысл в конктексте конкретного сценария в определенной предметной области. и больше нигде - это бизнес логика.
И в чем проблема при использовании классики?
и что? раз он безполезен в отрыве от других частей приложения, то он должен быть обязательно объединен с ними! Вы ведь именно так приводите к мысли, что домен не может выделен, так как он без каких-то инструментов.
Во первых это лишь сотый раз доказывает что ваша святая мантра про "домены" бесполезная и не состоятельная. Ибо это всего лишь логика обработки нажатия кнопки. логика проверки авторизован юзер или нет и т.п.
Во вторых нет, в том и дело что он ничего не должен, он находится ровно там, где удобнее всего ему быть в конкретном сценарии, под он, я имею ввиду часть логики приложения, а не несуществующие вещи.
Даже если они говорят, что понимают - они ошибаются
Они "видели" НЛО
во все нет. И там и там это некоторое усложнение чего-то, что бы потом получить профит. То что вы не можете этого осознать - ваша проблема. Примеры были даны.
Опять не верно. Потому что: - В случае с TS да, ты немного усложняешь и получаешь реальный профит. - В случае с FSD ты много усложняешь и не получаешь профит, а получаешь только геморрой, борьбу самим с собой, борьбу с папками, борьбу с этой "архитектурой" чтобы каждый раз делая элементарную вещь(но гордо называя её сложной) ты думал как же угадить этому франкенштейну и куче ограничений в довесок.
Более близкая аналогия классики и fsd ещё вот такая: - Классика это когда ты начал заниматься спортом в меру, как физкультура и реально получаешь профит в виде пользы здоровья, хорошего самочувствия, профилактики сердечных заболеваний, диабета и т.д. и т.п. - FSD это когда ты ушёл в жесткий бодибилдинг с кусами химии, запредельными весами и т.п. и умер не дожив до 30, и те годы пока ты жил были для тебя пыткой, потому что ты жил в зале, постоянные диеты, двигаться тяжело из-за огромной массы, всё тяжело. А ради чего?
я дал вполне конкретный пример проекта. О чем вы говорите?
Это где просто список папок?) Это даже в таком примере где специально все не сгруппировано и доведено до абсурда всё равно по факту проблем то нет.
отлично и в итоге вам нужно или помнить все нужные имена или что бы они были сразу тут в редакторе кода.
Что?) Я писал вот это ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно. Тут не надо ничего помнить и знать, зашли в код интересующей вас страницы нашли что надо. Допустим вам нужен компонент с раскрывающимся списком, он есть на странице X и идет после блока "Описание:", зашли в код этой страницы ctrl+f - "описание" и смотри ниже, там и будет нужный компонент. А если у вас SCSS + CSS modules то прямо в верстке в имени класса будет путь до компонента. Или же React Dev Toolks подскажет название) В общем вариантов масса и все крайне быстрые.
Но с вашей логикй - вам можно вообще разбить на разделение. Вам не нужно в том примере с 200 компонентами их разбивать по папкам. более того, с учетом ваших аргументов можно туда сложить и хуки, и стейты, и утилиты. Следуйте kiss - не усложняйте.
ну так выходит, что закрытость методов плохо. Ведь там ровно те же аргументы хза и против) Выходит вы против и приватных методов.
Если не мешает разработке, то по барабану, открыты или закрыты.
Я перечисляю какие проблемы можно получить в классике, и как их решает ддд.
С тем же успехом я бы мог объяснять как хорошо тс решает некоторые проблемы, и точно так же меня бы не слушали и говорили, что js - идеален и все типы это лишняя и бессмысленная сложность. Вообще 0 разницы.
Все "проблемы" которые перечисляете связаны с якобы сложностью в навигации. Но на самом деле это не так. Ещё одна "проблема" если есть циклическая зависимость, только опять же в этом нет никаких проблем, если так удобно, то пусть себе все будет, на работоспособность это не влияет. Вот и все ваши "проблемы", которые на самом деле ими не являются в классике. А вы предлагаете платить огромную цену за потенциальное их "решение", но решать там нечего, а вместо этого вы только плодите головную боль и упущенную выгоду для бизнеса в геометрической прогрессии когда используете FSD.
Вполне типичный кейс когда митрофронты используют один и тот же кит.
Логично, потому что без него они бесполезны.
голословное не верное высказывание. Почему-то я выделяю и это удобно. Вы просто не понимаете, что такое выделение бизнес логики. И продолжаете говорить что чего-то нет, хотя вы просто не пнимаете, что это такое.
И как именно вы что-то выделяете в отрыве от всего остального? Вот чтобы ваша выделенная бизнес логика имела хоть какой-то смысл.
Согласно вашей логике - выделять стейт в отдельны класс в принципе не не нужно, так как сам по себе без других компонентов он ничего не дает. Браво! срочно объедените стейт и отображение.
Я так не говорил. Ибо стейт != бизнес логика в отрыве от всего. Стейт это общая часть приложения, без него приложение бесполезно. Так как стейт бесполезен без других компонентов системы.
собственно что и требовалось доказать - вы не понимаете, что такое домен и как его использовать, а потом пытаетесь доказать что они не могут существоать. Для начала разберитесь с этим а потом делайте утверждения.
Вы тоже не понимаете что такое "домен". Делаете вид что понимаете, нельзя понимать то, что оторвано от реальности.
увы, слепое отрицание - именно так и проявляется. Например некоторые люди так отрицали тс. Только спустя какое-то время они согласились с его удобством.
Да нет, не слепое. И опять, TS и FSD вещи не сравнимы в данном контексте, TS == JS, именно "==". А FSD !== классике. Это диаметрально противоположная вещь.
Я хотя бы указывал на конкретные примеры
Рассуждая "доменами" это не конкретные примеры. Это абстракции.
ухх. я так понимаю про с ддд не разобрались.
Разобрался давно, оно не работает во фронте без боли и страданий. А я не люблю боль и страдания, простая арифметика.
конечно, если ты знаешь имя. Удачи искать код, когда ты не знаешь имя. Удачи между ним переключатся когда дерево файлов проекта стало практически бессмысленным.
ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно.
Принцип ровно тот же: вы считаете что закрытость определенного кода это плохо - так что я лишь продолжил вашу логику.
Плохо, при условии если это мешает разработке. В остальных случая по барабану.
Молоток - это разбиение проекта по ддд
Ага, конечно же))) И как же эти "идиоты" не использующие ддд живут, кошмар просто. Счастливые люди.
Только в следующий раз вступая в полемику сразу укажите что вы не понимаете, что такое домены и не хотите понимать.
Так вы сами не понимаете, говорите что вокруг одни проблемы и всё сложно, при это используете "домены" и "молоток" ддд. А я использую классику и говорю что все легко и просто. Так где выигрыш? Я думаю когда все легко и просто это и есть Win Win. А когда все сложно и постоянно надо решать какие-то "проблемы" которые вы сами себе создаете на каждом шагу это Epic Fail. Опять же простая арифметика. Как можно говорить что боль и страдания это хорошо, а простота и лёгкость это плохо?
Это когда говорят. а вот Вася сказал "...", поэтому я так делаю/считаю. И это я порицаю.
Бизнес логика вполне выделяется. Микрофронтенды и микросервисы этому подтверждение.
Разумеется, потому что они идут в паре с инструментарием, с помощью которого бизнес логика обретает смысл. А сама по себе отдельно бизнес логика никуда не выделяется, ибо она сама по себе никому не нужна.
Страница логина - это страница логина. Кто спорит? И она так же смело принадлежать домену, например авторизации, в котором будет десяток страниц и компонентов.
Вот видите, как только доходит до конкретики всё сразу становится элементарным. Вообще не проблема, пускай себе лежат страницы связанные с авторизацией в подпапке auth. Вообще в этом нет проблем в классической архитектуре, потом что они их не создает)
Вы не видите доменов, соответственно из этого вытекает ваша не способность эффективно с ними работать.
Вижу реальные вещи, например когда компоненты для работы с формой можно сгруппировать в formFields или как угодно можно называть. Но для меня это просто группировка для удобства, а не "домен" ради "домена".
Вас ноль проблем касающихся разбиения папок?
Были бы они, я бы искал пути их решения, а не мучался)
И главное не забыть побольше вставить про то как собеседник манипулирует, это точно докажет что вы правы.
Нет не докажет, но укажет на дешевые манипуляции. В самом по себе явлении манипуляция нет ничего удивительного, это распространенное явление в обществе.
Простой пример, почему именно дешевые манипуляции бесят людей: - Гражданину задают совершенно конкретный вопрос: "Почему в бюджете вы указали что освоили деньги на строительство больницы, по адресу г. X, ул. Y, дом Z, а больницы нет? Ведь вы лично ставили подпись и в прошлом году говорили что до DD.MM.YYYY больница будет построена. А уже год прошел с этой даты." - И вот этот самый гражданин начинает рассказывать про то, всё что угодно, но только не про конкретно поставленный вопрос.
Доменов не существует, соответственно микрофронты и микросервисы невозможно выделить и нужно слить?
Микрофронты и микросервисы вполне себе выделяются в отдельные вещи, но это не несет прямой связи с "доменами" и бизнес логикой. Например микросервис авторизации, с одной стороны сам по себе, а с другой стороны от него все (якобы независимые "домены") зависят. И вот ты вроде A вынес, но A без B ничего из себя не представляет, так же как B без A. Вот тебе и связь все ко всем, которую вы так боитесь почему-то. Я то не боюсь, более того наоборот, она максимально удобна.
Так же вы утверждаете, что в пространстве на 300 компонентов проще искать чем в пространстве на 30 компонентов. Конечно это так, кто может подумать иначе?
Да. 1) CTRL+F в IDE пофигу сколько там компонентов в пространстве. 2) CTRL+Click в IDE пофигу сколько там компонентов в пространстве.
Так же выходит, что мы должны отказаться от приватных методов и вложенных компонентов.
С чего это вдруг? Тысячный раз повторяю, классика не накладывает жестких ограничений, т.е. вы не должны, что-то делать просто потому что. Разумеется если метод/класс/компонент/whatever не использует кто-то из вне, то его можно делать приватным. Ключевое слово можно. Хочешь будет приватное, хочешь нет, вообще без разницы по большому счету. На работоспособность программы не влияет.
P.s. казалось бы просто осмыслить что такое домен и как его можно реализовать - и все обретёт смысл, но видимо нужно продолжать бить гвоздь деревянной ручкой и утверждать что молоток не работает
Я то как раз бью по гвоздю молотком, заметьте, это у меня нет никаких проблем с архитектурой и с навигацией и т.п., у меня всё прекрасно и просто. А вы предлагаете развернуться на 180 и начать обретать проблему за проблемой и выдумывать проблему за проблемой. А мне и без проблем хорошо живется) Я их просто себе не создаю специально сам и все дела.
Я реалист, я знаю что чат это просто чат. а не "домен". Я знаю что страница логина это просто страница логина а не "домен".
Я не вижу никаких "доменов", я вижу только чат, страницу логина, список комментариев. Я вижу реальные вещи, а не вымышленные. Думаю реальными вещами, а не вымышленными. И главное вещи которыми я думаю максимально конкретные и понятные, а не размытые и не имеющие строго описания. У меня 0 проблем касающихся архитектуры, т.к. я использую классику. У вас наоборот целый набор проблем, которые вы пытаетесь решить способами, не предназначенными для этого. А я эти "проблемы" (в фронтовых SPA) решил лет 7 назад и не испытываю их по сей день. Т.к. лекарство предельно простое.
Вы говорите "домен" то, "домен" сё, а на самом деле это пустое место. Я не пляшу вокруг пустого места. И не выстраиваю архитектуру вокруг пустого места.
Вы пытаетесь выделить бизнес логику, как что-то самодостаточное, особенное и якобы не зависящее от других частей системы. Но так не бывает и не работает, т.к. все переплетено. Без вариантов.
Я пытаюсь вас слышать, но вы всегда манипулируете абстрактными вещами, т.к. легко можно выдумать что они представляют какую-то сложность и проблему, а как только мы приходим к конкретике, то у вас все рушится и вы опять начинаете уходить в абстракции и "домены", которые на самом деле ничем конкретным не являются, кроме как словом.
можно привести слова, где говорится, что-то относящееся к домену чат не лежит в нем?
Опять манипуляции уровня начальных классов. Чат не использует кнопки? Чат не использует инпуты? Чат не использует приведение дат к единому формату? И т.д. и т.п. Ваш чат ничто, без этих элементов. Которые у вас лежат в shared и используются вашим "доменом" чата. Поэтому то, что касается чата у вас лежит не только в папке с ним. Привет лицемерная религия с двойными стандартами.
не совсем понимаю вопрос. Давайте разберем: у нас есть датты которые нужно показывать исходя из локали пользователя, или от его настроек. Выглядит, как обычный инструментарий, и должен лежать в shared.
Да, вот именно. Они и должны лежать в shared. И без него(инструментария из shared), ваши "домены" не являются работоспособными, а значит они зависят от него. Вот опять ваша религия ударила в грязь лицом
Абсолюьно верное высказывание, которое мне никак не противоречит. Ваш компонент не имеет никакого смысла без реакта, следует ли из этого, что вы код реакта должны раместить в компоненте? Вот и кит пусть лежит отдельно, а кто хочет - пусть к нему обращается.
Так у меня с этим нет проблем)) Это у вас религия что все что касается "Домена" должно лежать в его папке. Только есть нюанс, ваш "домен" на самом деле это ничто, пустышка, пустой слово.
Ваш компонент не имеет никакого смысла без реакта
Да, поэтому у меня именно реактовский компонент и у меня нет с этим проблем) Так же как чат не имеет никакого смысла без кнопок, инпутов и т.д. он зависим от всего этого. Это это всего лишь чат. Страница с чатом, виджет часа, вообще без разницы. Просто чат и чат. А не всемогущий "домен".
Все что касается бизнеслоки домена лежит в домене. А причем тут инструментарий так и не понятно. В кнопке из material-ui есть бизнеслогика или привязанность к домену? нет. Так почему она должна лежать в его рамках?
Вот именно что не должна. Как много чего ещё не должно. Но мы уже разоблачили ваши "домены". Поэтому больше опираться на них не будем, они ничто.
Подводя итог:
Ваш "домен" — ничто без shared/помойки или как вы там называете общие вещи. И он не является чем-то самодостаточным от слова совсем. Поэтому весь культ вокруг "ничто" бессмысленный.
почему все? я складываю туда только то, что не связано с бизнес логикой. Соотвсетственно, я не понимаю проблемы: у нас в shared лежит всякий инструментарий
Первый момент: С ваших слов все что касается "домена" chat лежит не только в папке chat? А это противоречит вашим убеждениям из вашей "доменной" религии. И какой тогда в этом смысл?
Второй момент: Т.е. если вы не будете форматировать дату и показывать пользователю из России YYYY-MM-DD вместо DD.MM.YYYY , то это ничего страшного, это к бизнес логике отношения не имеет? То есть если вы не будете показывать кнопку "Войти", то это ничего страшного, это не относится к бизнес логике?
Бизнес логика не имеет никакого смысла и не несет ни какой пользы без инструментария. Ибо без него ей нельзя воспользоваться.
Какая разница если в конечном счета это все один проект, одно без другого не несет практической пользы.
Кому нужны кнопки нажатие на которые ничего не делает? Кому нужна бизнес логика корзины товаров, в которой нет кнопок что оформить заказ и нет инпутов чтобы ввести телефон, адрес и т.п.?
Так что, получается используя shared вы лицемерите говоря что у вас все разбито по "доменам" и всё что касается "домена" лежит в его попке. Вы обложили себя ограничениями и ненужными правилами, а сами тайком их нарушаете. Но при этом говорите какие они классные и какой у вас классный подход. А то, что он не сопоставим с реальностью это пофигу.
Все что относится к домену - лежит все еще к домену.
Чем больше проект растет, чем ваджнее его структурированность и согласованность
Всё равно не вижу где тут в классике проблемы, только если вы сами специально создаете надуманными примерами. Ну большой стал проект и что теперь. Ну теперь <Button /> использует не 10 страниц, а 110. Теперь <Input /> и <Select /> не на 3х страница, а на 53. Какая разница то? Просто стало больше всего и все, при том же подходе - Keep It Simple.
Скажите, какая принципиальная разница будет между тем, что домен будет на первом уровне папок (как у меня), а не на втором(как у вас)?
Принципиальная такая - в моем случае это не будет каким-то правилом, это будет продиктовано удобством. А так, как жестких правил и ограничений нет, то и политика "все что касается chat должно лежать в папке chat" тоже не актуальна для меня) Все лежит ровно так, где удобно и так, как удобно. Это самое главное правильно, что все было удобно, легко и просто)
Если вы одно тяжело принимали, может и сейчас такаяже проблема?
Потому что для избегания дублирования вы все кладете в shared. А потом вы гордо говорите, все что относится к моему "домену" находится в одной папке. Но есть нюанс, все остальное что он тянет из вне, это не считается и мы тут закрываем глазки. Классно)
А чтобы ваши слова про все что касается домена только в его папке были правдой, то выход один, дублирование кода. Никаких тебе общих кнопок, никаких тебе общих функций, ведь тогда святая концепция нарушается.
Более того, разве вы не писали что изначально тс вам не понравился?
Так и есть, я же говорю я не фанатик, если бы в FSD я видел реальные удобства перебивающие классику по совокупности взвешенных факторов, я бы использовал FSD. Ну и TS тут не особо подходит под аналогию, потому что JS и TS это грубо тоже самое, только в TS есть возможность типизировать. А FSD и классика диаметрально противоположные.
Почему бы не взять пример из спорта: вот вы любите бегать на скорость, а я полумарафоны. Следует ли что одно хуже другого? вовсе нет.
Опять не та аналогия, конечно для вас она удобна) Но более корректная в данном случае аналогия из спорта будет такая: Мы оба бежим марафон в +25 градусов. - Я бегу в современно легкой футболе, шортах и максимально удобных кроссовках. - Вы бежите в зимней фуфайке, толстых штанах и в берцах туго затянутых.
Почему вы так побежали? На этот вопрос нет ответа рационального. Просто вы так захотели, вам так нравится. Отсюда и специфичные вкусы.
в вашей структуре, очень много открытых для использования компонентов и функций, так как они все доступны на глобальном уровне.
И в этом огромный плюс, в виде удобства, гибкости, скорости и отсутствия лишнего дублирования.
У меня же обратная ситуация - ничего из того что я осознано пометил как открытое для использования- наружу и не торчит. соотвественно сложнее получить связь всех ко всем.
Ровно как и сложнее делать вообще все, что касается работы над таким проектом. А связь всех ко всем во первых высосана из пальца и не реалистична от слова совсем, во вторых возможность связи между компонентами системы на практике и в реальном мире дает только плюсы. А минусы как обычно только абстрактные и теоретические в специально выдуманных сценариях. И все равно эти "минусы" ничтожны по сравнению с плюсами.
Да нет, просто если не боятся больших проектов, то все выходит вполне естественно. Но вот вы уже скатываетесь к аргументу к личности.
Каждый человек личность и его мышление продиктовано именно его личностью, а не чем то ещё. Да есть люди у которых вкусы специфичны, да есть люди которые нюхают клей, и т.п. Ну и что теперь, вот такие они, все мы разные и каждый уникален. Переход на личности это очень растяжимое понятие, вы сейчас его драматизировали, т.к. вы не считаете, что любить древние огромные проекты с кучей ограничений это нормально, я же просто указал, что в вашем конкретном случае есть особые предпочтения, они не объективные, а просто вам так нравится и считаете что так хорошо.
Вы не пишите на фсд, но утверждаете что дублирование есть. Я на нем пишу и утверждаю что на моем проекте дублирования вытекающего из фсд нет.
Ключевое - "дублирования вытекающего из фсд нет." Оно вытекает из DDD из которого вытекает FSD, вы просто решили таким образом прикрыть FSD. Настоящий FSD как и настоящий DDD без дублирования невозможен, иначе весь их "смысл" теряется и вы уже получается лицемерите. Это говорить что вы веган, но есть сыр)
Вы не пишите на фсд, но утверждаете
Чтобы понять что я вижу на дорого коровью лепешку мне не надо пробовать ее на вкус, достаточно просто взглянуть) FSD не исключение)
Я сейчас возьму один из проектов написанных на классике, и попрошу в них что-то найти. Вы попробуете или найти нужный код по предложенному мной домену, или предложить, что можно сделать для упрощения его поиска. https://playcode.io/2233829.Давайте, вот тут посмотрим, что у нас есть по чатам? Как быстро вы нейдете весь функционал связанный с ними.
Ну во первых 5 секунд, и это без шуток. Ctrl+f и написал chat.
Во вторых в вашем наигранном примере даже это наиграно, когда доходит до такого, все эти компоненты просто в папку chat/ складывают и все)
Ну если у вас проблемы с навигацией и вы не знаете где лежит компонент и не знаете его названия, то да, по сути это самый быстрый и эффективный способ. Но вы всегда можете использовать альтернативный метод - погадать на кофейной гуще, вызвать пиковую даму и поговорить с "доменами", они вам скажут где искать. Но этот вариант будет несколько дольше по времени.
А мне не избыточно, мне нормально)
Конечно, и не пользуюсь IDE и не пользуюсь компьютером тоже.
Мне маловато будет)
И у меня, только в
src/componentsНет. Все они распределены и сгруппированы.
К чему? К фейковым мыслям что в
src/componentsна одном уровне вложенности будет лежать 2200 компонентов из ваших фантазий? :DЯ не создаю "домены" и не вызываю пиковую даму и т.п. Я делаю группировку исходя из логики и здравого смысла.
Настолько банальные до абсурда вещи опускаются когда речь идёт о ограничениях. Разумеется никто не будет класть страницу в хуки или utils.
Я не трачу на нее время. Мне НЕ надо думать а вот это, это что, "демон" или widget или feature или entity или shared или пиковая дама или
/ui/ui/ui/ui/ui.. А вот точно ли это entity? а может все таки feature. Ну ладно, а потом бац и на код ревью fsd фанатик говорит, а не, это вообще widget и ещё ты не достаточно много/ui/ui/ui/ui/uiнасоздавал, нужно больше.У меня всё элементарно:
Страницы сразу идут в
src/pagesОбщие компоненты сразу идут в
src/componentsЛейауты сразу идут в
src/layoutsВложенные компоненты сразу идут в
./componentsТут 0 дилем, 0 спорных моментов, 0 недопониманий. Поэтому умножаем на коэффициент 0 и получаем 0 extra time на ведение и поддержание архитектуры.
Я не знаю о чем вы, у меня нет проблем, и не было) Я хоть говорил что у меня есть какие-то проблемы?) Я ничего не превозмогаю, потому что нет объекта превозмогания) У меня же архитектура здорового человека используется на проектах)
Складывайте если хотите)
У меня нет такой логики) Я сто раз показывал скриншот как я группирую файлы и папки) Ваши фантазии не знаю)
Моего разбиения хватает выше крыше) А всё сверх этого уже избыточно и ничего не решает, а только создает) См. скриншот которой я сто раз скидывал.
Потому что в классике оно сюрприз логическое и интуитивное. А это мы одобряем и всю жизнь одобряли.
Остальные 170 общих компонентов которые все части системы используют значит выкинули в мусору, умно. (Ниже выясняется что оказывается это были не общие компоненты, а вообще все компоненты в проекте в вашем примере со списком компонентов)
Так бы и сказали, что это не общие компоненты которые принято держать в папке
src/components, а вообще все компоненты в проекте. Они буду распределены по папкамsrc/components/..,src/pages/..,src/pages/{pageName}/components/..,src/layouts/..Вот прям как тут, давным давно показано:Посмотрите дату где впервые скриншот появился. Какой "вот это" поворот? Это то, как я с 2017 года группирую файлы и папки.
Ну если лично вы хотите, кладите, ваш проект, ваши правила) Я страницы кладу в
pages) Самое названиеpagesнаверное о чем-то говорит да?)Ну вы утрируете сильно и драматизируете) У вас просто фанатичное помешательство на FSD и папках, а я группирую все так, как диктует здравый смысл и логика) А не ограничения и правила которые силой мне решил навязать какой-то сайтик где хранится описание Freaky Sliced Design.
Т.е. в shared не место для общих компонентах приложения которые используются разными его частями сколько угодно раз?) Интересненько
Да не вопрос, я в этом не сомневаюсь. Но это не дает профита. В классике их тоже можно легко сгруппировать по папкам. Более того, я их группирую по определённым признакам и у меня нет простыни из 200 компонентов. Не знаю откуда вы это взяли вообще.
У вас опять все строится вокруг группировки по папкам, в классике это делать легко и непринужденно, более того никаких ограничений в этом нет.
Если бы я говорил что классика запрещает группировки и нужно только все папки внутрь src/ засовывать, то да, конечно я бы безоговорочно проиграл.
Но в классике то есть группировка и она ничего не запрещает, какое тут может быть поражение? Хоть группируй сильнее, хочешь слабее, вообще ноу проблемос.
Дык пожалуйста, пускай себе там лежат эти 200 общих компонентов в папке src/components, и даже без группировок. Вот такой у нас проект, много в нем общих компонентов. Что от этого меняется? Алгоритм нахождения нужного компонента/хука/чего угодно не зная названия неизменен, я описывал его выше. И это не имеет отношения к тому, классика или нет. Если в проекте 200 общих компонентов, то они просто будут лежать в папке shared если используется fsd.
Вы писали что по "моей" логике, ничего в папки складывать не надо, можно просто на плоском уровне все пихать и всё. А я просто показал(сотый раз) что я так не делаю и у меня есть папки под конкретные нужны проекта.
Во время создания думаете куда что положить, вариантов то масса (features, enities, widgets, shared, pages) боретесь с ограничениями и подстраиваетесь под них, плодите лишние папки просто ради папок, потому что так заведено в fsd. Это всё в довесок даёт минус мораль, что тоже сильно снижает производительность.
Во время условных правок вы во первых ищете все по кусочками разбросанными по всевозможным features, enities, widgets, shared, pages, по бесконечным
/ui/ui/ui/ui/ui/ui, опять беретесь с ограничениями, подстраиваетесь под жесткие правила. Этот сценарий всё так же в довесок даёт минус мораль, что тоже сильно снижает производительность.И это только то, что прям на поверхности, без дополнительных нюансиков в виде код ревью у фанатика fsd, которое проходить каждый раз это целое испытание.
И вот по совокупности всего это bull shit'a да, скорость разработки серьезно страдает и да, минус мораль вносит огромную лепту в это, а не только сам факт убогости fsd.
Т.е. вы тот самый проповедник? Вы там самая истина в последней инстанции? Получается вы правы, я не прав, просто потому что вы так решили, лихо однако)
"Домены" это лишь абстракция и иллюзия. А микрофронты разбивают по логическим частям приложения и они не независимы друг от друга, просто разделены но не независимы. Это для меня в порядке вещей, потому что так и должно быть. И не вижу проблем при использовании классики в данном случае.
Тогда бы вы не использовали FSD.
И в чем проблема при использовании классики?
Во первых это лишь сотый раз доказывает что ваша святая мантра про "домены" бесполезная и не состоятельная. Ибо это всего лишь логика обработки нажатия кнопки. логика проверки авторизован юзер или нет и т.п.
Во вторых нет, в том и дело что он ничего не должен, он находится ровно там, где удобнее всего ему быть в конкретном сценарии, под он, я имею ввиду часть логики приложения, а не несуществующие вещи.
Они "видели" НЛО
Опять не верно. Потому что:
- В случае с TS да, ты немного усложняешь и получаешь реальный профит.
- В случае с FSD ты много усложняешь и не получаешь профит, а получаешь только геморрой, борьбу самим с собой, борьбу с папками, борьбу с этой "архитектурой" чтобы каждый раз делая элементарную вещь(но гордо называя её сложной) ты думал как же угадить этому франкенштейну и куче ограничений в довесок.
Более близкая аналогия классики и fsd ещё вот такая:
- Классика это когда ты начал заниматься спортом в меру, как физкультура и реально получаешь профит в виде пользы здоровья, хорошего самочувствия, профилактики сердечных заболеваний, диабета и т.д. и т.п.
- FSD это когда ты ушёл в жесткий бодибилдинг с кусами химии, запредельными весами и т.п. и умер не дожив до 30, и те годы пока ты жил были для тебя пыткой, потому что ты жил в зале, постоянные диеты, двигаться тяжело из-за огромной массы, всё тяжело. А ради чего?
Это где просто список папок?) Это даже в таком примере где специально все не сгруппировано и доведено до абсурда всё равно по факту проблем то нет.
Что?) Я писал вот это
ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно.Тут не надо ничего помнить и знать, зашли в код интересующей вас страницы нашли что надо. Допустим вам нужен компонент с раскрывающимся списком, он есть на странице X и идет после блока "Описание:", зашли в код этой страницы ctrl+f - "описание" и смотри ниже, там и будет нужный компонент. А если у вас SCSS + CSS modules то прямо в верстке в имени класса будет путь до компонента. Или же React Dev Toolks подскажет название) В общем вариантов масса и все крайне быстрые.
Если не мешает разработке, то по барабану, открыты или закрыты.
Все "проблемы" которые перечисляете связаны с якобы сложностью в навигации. Но на самом деле это не так. Ещё одна "проблема" если есть циклическая зависимость, только опять же в этом нет никаких проблем, если так удобно, то пусть себе все будет, на работоспособность это не влияет. Вот и все ваши "проблемы", которые на самом деле ими не являются в классике. А вы предлагаете платить огромную цену за потенциальное их "решение", но решать там нечего, а вместо этого вы только плодите головную боль и упущенную выгоду для бизнеса в геометрической прогрессии когда используете FSD.
Логично, потому что без него они бесполезны.
И как именно вы что-то выделяете в отрыве от всего остального? Вот чтобы ваша выделенная бизнес логика имела хоть какой-то смысл.
Я так не говорил. Ибо стейт != бизнес логика в отрыве от всего. Стейт это общая часть приложения, без него приложение бесполезно. Так как стейт бесполезен без других компонентов системы.
Вы тоже не понимаете что такое "домен". Делаете вид что понимаете, нельзя понимать то, что оторвано от реальности.
Да нет, не слепое. И опять, TS и FSD вещи не сравнимы в данном контексте, TS == JS, именно "==". А FSD !== классике. Это диаметрально противоположная вещь.
Рассуждая "доменами" это не конкретные примеры. Это абстракции.
Разобрался давно, оно не работает во фронте без боли и страданий. А я не люблю боль и страдания, простая арифметика.
ctrl + click в помощь. Страница на которой находится "подопытный" в помощь. В ее коде все видно и названий никаких знать не нужно.
Плохо, при условии если это мешает разработке. В остальных случая по барабану.
Ага, конечно же))) И как же эти "идиоты" не использующие ддд живут, кошмар просто. Счастливые люди.
Так вы сами не понимаете, говорите что вокруг одни проблемы и всё сложно, при это используете "домены" и "молоток" ддд. А я использую классику и говорю что все легко и просто. Так где выигрыш?
Я думаю когда все легко и просто это и есть Win Win.
А когда все сложно и постоянно надо решать какие-то "проблемы" которые вы сами себе создаете на каждом шагу это Epic Fail.
Опять же простая арифметика. Как можно говорить что боль и страдания это хорошо, а простота и лёгкость это плохо?
Это когда говорят. а вот Вася сказал "...", поэтому я так делаю/считаю. И это я порицаю.
Разумеется, потому что они идут в паре с инструментарием, с помощью которого бизнес логика обретает смысл. А сама по себе отдельно бизнес логика никуда не выделяется, ибо она сама по себе никому не нужна.
Вот видите, как только доходит до конкретики всё сразу становится элементарным. Вообще не проблема, пускай себе лежат страницы связанные с авторизацией в подпапке auth. Вообще в этом нет проблем в классической архитектуре, потом что они их не создает)
Вижу реальные вещи, например когда компоненты для работы с формой можно сгруппировать в formFields или как угодно можно называть. Но для меня это просто группировка для удобства, а не "домен" ради "домена".
Были бы они, я бы искал пути их решения, а не мучался)
Нет не докажет, но укажет на дешевые манипуляции. В самом по себе явлении манипуляция нет ничего удивительного, это распространенное явление в обществе.
Простой пример, почему именно дешевые манипуляции бесят людей:
- Гражданину задают совершенно конкретный вопрос: "Почему в бюджете вы указали что освоили деньги на строительство больницы, по адресу г. X, ул. Y, дом Z, а больницы нет? Ведь вы лично ставили подпись и в прошлом году говорили что до DD.MM.YYYY больница будет построена. А уже год прошел с этой даты."
- И вот этот самый гражданин начинает рассказывать про то, всё что угодно, но только не про конкретно поставленный вопрос.
Микрофронты и микросервисы вполне себе выделяются в отдельные вещи, но это не несет прямой связи с "доменами" и бизнес логикой. Например микросервис авторизации, с одной стороны сам по себе, а с другой стороны от него все (якобы независимые "домены") зависят. И вот ты вроде A вынес, но A без B ничего из себя не представляет, так же как B без A. Вот тебе и связь все ко всем, которую вы так боитесь почему-то. Я то не боюсь, более того наоборот, она максимально удобна.
Да.
1) CTRL+F в IDE пофигу сколько там компонентов в пространстве.
2) CTRL+Click в IDE пофигу сколько там компонентов в пространстве.
С чего это вдруг? Тысячный раз повторяю, классика не накладывает жестких ограничений, т.е. вы не должны, что-то делать просто потому что. Разумеется если метод/класс/компонент/whatever не использует кто-то из вне, то его можно делать приватным. Ключевое слово можно. Хочешь будет приватное, хочешь нет, вообще без разницы по большому счету. На работоспособность программы не влияет.
Я то как раз бью по гвоздю молотком, заметьте, это у меня нет никаких проблем с архитектурой и с навигацией и т.п., у меня всё прекрасно и просто. А вы предлагаете развернуться на 180 и начать обретать проблему за проблемой и выдумывать проблему за проблемой. А мне и без проблем хорошо живется) Я их просто себе не создаю специально сам и все дела.
Я реалист, я знаю что чат это просто чат. а не "домен". Я знаю что страница логина это просто страница логина а не "домен".
Я не вижу никаких "доменов", я вижу только чат, страницу логина, список комментариев. Я вижу реальные вещи, а не вымышленные. Думаю реальными вещами, а не вымышленными. И главное вещи которыми я думаю максимально конкретные и понятные, а не размытые и не имеющие строго описания. У меня 0 проблем касающихся архитектуры, т.к. я использую классику. У вас наоборот целый набор проблем, которые вы пытаетесь решить способами, не предназначенными для этого. А я эти "проблемы" (в фронтовых SPA) решил лет 7 назад и не испытываю их по сей день. Т.к. лекарство предельно простое.
Вы говорите "домен" то, "домен" сё, а на самом деле это пустое место. Я не пляшу вокруг пустого места. И не выстраиваю архитектуру вокруг пустого места.
Вы пытаетесь выделить бизнес логику, как что-то самодостаточное, особенное и якобы не зависящее от других частей системы. Но так не бывает и не работает, т.к. все переплетено. Без вариантов.
Я пытаюсь вас слышать, но вы всегда манипулируете абстрактными вещами, т.к. легко можно выдумать что они представляют какую-то сложность и проблему, а как только мы приходим к конкретике, то у вас все рушится и вы опять начинаете уходить в абстракции и "домены", которые на самом деле ничем конкретным не являются, кроме как словом.
Опять манипуляции уровня начальных классов. Чат не использует кнопки? Чат не использует инпуты? Чат не использует приведение дат к единому формату? И т.д. и т.п. Ваш чат ничто, без этих элементов. Которые у вас лежат в shared и используются вашим "доменом" чата. Поэтому то, что касается чата у вас лежит не только в папке с ним. Привет лицемерная религия с двойными стандартами.
Да, вот именно. Они и должны лежать в shared. И без него(инструментария из shared), ваши "домены" не являются работоспособными, а значит они зависят от него. Вот опять ваша религия ударила в грязь лицом
Так у меня с этим нет проблем)) Это у вас религия что все что касается "Домена" должно лежать в его папке. Только есть нюанс, ваш "домен" на самом деле это ничто, пустышка, пустой слово.
Да, поэтому у меня именно реактовский компонент и у меня нет с этим проблем) Так же как чат не имеет никакого смысла без кнопок, инпутов и т.д. он зависим от всего этого. Это это всего лишь чат. Страница с чатом, виджет часа, вообще без разницы. Просто чат и чат. А не всемогущий "домен".
Вот именно что не должна. Как много чего ещё не должно. Но мы уже разоблачили ваши "домены". Поэтому больше опираться на них не будем, они ничто.
Подводя итог:
Ваш "домен" — ничто без shared/помойки или как вы там называете общие вещи. И он не является чем-то самодостаточным от слова совсем. Поэтому весь культ вокруг "ничто" бессмысленный.
Первый момент:
С ваших слов все что касается "домена" chat лежит не только в папке chat? А это противоречит вашим убеждениям из вашей "доменной" религии. И какой тогда в этом смысл?
Второй момент:
Т.е. если вы не будете форматировать дату и показывать пользователю из России
YYYY-MM-DDвместоDD.MM.YYYY, то это ничего страшного, это к бизнес логике отношения не имеет? То есть если вы не будете показывать кнопку "Войти", то это ничего страшного, это не относится к бизнес логике?Бизнес логика не имеет никакого смысла и не несет ни какой пользы без инструментария. Ибо без него ей нельзя воспользоваться.
Какая разница если в конечном счета это все один проект, одно без другого не несет практической пользы.
Кому нужны кнопки нажатие на которые ничего не делает?
Кому нужна бизнес логика корзины товаров, в которой нет кнопок что оформить заказ и нет инпутов чтобы ввести телефон, адрес и т.п.?
Так что, получается используя shared вы лицемерите говоря что у вас все разбито по "доменам" и всё что касается "домена" лежит в его попке. Вы обложили себя ограничениями и ненужными правилами, а сами тайком их нарушаете. Но при этом говорите какие они классные и какой у вас классный подход. А то, что он не сопоставим с реальностью это пофигу.
Ага, обязательно)) Это мы уже выяснили)
Всё равно не вижу где тут в классике проблемы, только если вы сами специально создаете надуманными примерами. Ну большой стал проект и что теперь. Ну теперь <Button /> использует не 10 страниц, а 110. Теперь <Input /> и <Select /> не на 3х страница, а на 53. Какая разница то? Просто стало больше всего и все, при том же подходе - Keep It Simple.
Принципиальная такая - в моем случае это не будет каким-то правилом, это будет продиктовано удобством. А так, как жестких правил и ограничений нет, то и политика "все что касается chat должно лежать в папке chat" тоже не актуальна для меня) Все лежит ровно так, где удобно и так, как удобно. Это самое главное правильно, что все было удобно, легко и просто)
Точно не в этом случае
Потому что для избегания дублирования вы все кладете в shared. А потом вы гордо говорите, все что относится к моему "домену" находится в одной папке. Но есть нюанс, все остальное что он тянет из вне, это не считается и мы тут закрываем глазки. Классно)
А чтобы ваши слова про все что касается домена только в его папке были правдой, то выход один, дублирование кода. Никаких тебе общих кнопок, никаких тебе общих функций, ведь тогда святая концепция нарушается.
Так и есть, я же говорю я не фанатик, если бы в FSD я видел реальные удобства перебивающие классику по совокупности взвешенных факторов, я бы использовал FSD. Ну и TS тут не особо подходит под аналогию, потому что JS и TS это грубо тоже самое, только в TS есть возможность типизировать. А FSD и классика диаметрально противоположные.
Опять не та аналогия, конечно для вас она удобна) Но более корректная в данном случае аналогия из спорта будет такая:
Мы оба бежим марафон в +25 градусов.
- Я бегу в современно легкой футболе, шортах и максимально удобных кроссовках.
- Вы бежите в зимней фуфайке, толстых штанах и в берцах туго затянутых.
Почему вы так побежали? На этот вопрос нет ответа рационального. Просто вы так захотели, вам так нравится. Отсюда и специфичные вкусы.
И в этом огромный плюс, в виде удобства, гибкости, скорости и отсутствия лишнего дублирования.
Ровно как и сложнее делать вообще все, что касается работы над таким проектом. А связь всех ко всем во первых высосана из пальца и не реалистична от слова совсем, во вторых возможность связи между компонентами системы на практике и в реальном мире дает только плюсы. А минусы как обычно только абстрактные и теоретические в специально выдуманных сценариях. И все равно эти "минусы" ничтожны по сравнению с плюсами.
Каждый человек личность и его мышление продиктовано именно его личностью, а не чем то ещё. Да есть люди у которых вкусы специфичны, да есть люди которые нюхают клей, и т.п. Ну и что теперь, вот такие они, все мы разные и каждый уникален. Переход на личности это очень растяжимое понятие, вы сейчас его драматизировали, т.к. вы не считаете, что любить древние огромные проекты с кучей ограничений это нормально, я же просто указал, что в вашем конкретном случае есть особые предпочтения, они не объективные, а просто вам так нравится и считаете что так хорошо.
Ключевое - "дублирования вытекающего из фсд нет." Оно вытекает из DDD из которого вытекает FSD, вы просто решили таким образом прикрыть FSD. Настоящий FSD как и настоящий DDD без дублирования невозможен, иначе весь их "смысл" теряется и вы уже получается лицемерите. Это говорить что вы веган, но есть сыр)
Чтобы понять что я вижу на дорого коровью лепешку мне не надо пробовать ее на вкус, достаточно просто взглянуть) FSD не исключение)
Ну во первых 5 секунд, и это без шуток. Ctrl+f и написал chat.
Во вторых в вашем наигранном примере даже это наиграно, когда доходит до такого, все эти компоненты просто в папку chat/ складывают и все)