@Thekiba Привет! Как будет время, подскажи, мне пожалуйста. Мне нужно

понять как правильно размещать сущности в проекте если учитывать следующее:
1) Всю логику выносим из компонентов в сервисы
2) Соблюдаем принцип DIP
Вопрос где правильно размещать абстракции которые используют сервисы с логикой, redux?

В идеале абстракции должны лежать совсем отдельно А там, где редакс — там уже реализация абстраций

да, я понимаю, что абстракции должны лежать на своих уровнях. Для начала я пытаюсь понять как правильно это уровни разместить в проекте. 1) единые папки на весь проект 2) размещать в рамках модуля?

Лучше дробить по контекстам, чтобы в зависимости от контекста тащить нужные абстракции Если оно будет разбито по контекстам в одной папке проекта (аля базовый проект), то это норм

Допустим у нас есть модуль. В модуле smart компонент. Данный компонент использует сервис S (в котором вся логика компонента ), сервис S общается с redux через абстракцию F, redux использует абстракцию H. Вопрос: 1) smart должен зависеть от абстракции S или реализации? 2) как все это дело разместить по папкам( соблюсти DIP) в модуле?

под контекстом ты подрузумеваешь бизнес кейсы? типо user-info user-details product-owners и т.д?

Если компонент использует сервис S, то он должен зависеть только от него

Ага, их в том числе

в смысле должен зависеть от детали, вместо абстракции?

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

а вы можете отсортировать по "высоте" уровня. От высокого к низким, чтобы я понял как dip реализовать в рамках модуля. 1) dumb component 2) smart component 3) component logic service 4) redux 5) http service

А что имеется ввиду под redux и http service?

redux - класс в котором эффекты или акшины, который мутирует стору и дергает http service http service - класс который общается с беком

Меня смущает только smart и dump компоненты, и отсуствие доменного слоя здесь и указание вместо него redux (как я понял), а так связь выглядит здраво

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

я не знаю что такое доменный слой и как он реализуется в ангуляре.

redux - у меня это хранилище данных. smart/dumb описывают view.

Вот тут есть хорошая книга на эту тему, если есть возможность ознакомиться, то рекомендую https://www.angulararchitects.io/en/book/ Она бесплатная)

да супер спс

правильно я понимаю что components logic это самый высокий слой? т.к в нем лежит бизнес логика.

Оно будет по середине между UI и доменным слоем

я разобрался в dipendency inversion , сделал поправку в термине в русской и английской Википедиях, теперь хочу научиться его применять в файловой структуре модулей

Если я не ошибаюсь, то тут предложена файловая структура, и она не будет сильно отличаться от того, что хочется сделать на абстракциях Просто абстракции будут по соседству

дай пажалста пдф

По ссылке все есть, книга бесплатная

я почту светить не хотел. но уже.нашел временный ящик с аттачментами

Привет! Посмотрел, что-то сложно и не понятно. Смотри, если не применять этот сложный DDD, то правильно ли следующее утверждение. Уровень слоев в рамках модуля следующий: 1) компоненты (тут бизнес логика ) - самый высокий 2) хранилище данных - ниже чем компоненты 3) доступ к внешним ресурсам - ниже чем хранилище

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

И опиши что в твоем понимании выше/ниже ? Слишком абстрактное понятие, под которым ты можешь понимать что угодно