SP
Size: a a a
2021 November 23
NF
однажды ты забанишь сам себя за спам 😅
BT
всего лишь 20 раз эта ссылка была в чате
NF
we need more bananas, banana cases... banana stories, banana journey
A
Привет! А к какому слою правильнее относить интерфейсы внепроцессорных зависимостей?
Вот интерфейсы репозиториев относят к доменному слою, даже не смотря на то, что доменная модель не должна знать хранится ли где-то ее стейт.
А если это интерфейс для работы с файловой системой, то куда его? Кажется, что к апликейшн слою.
Но, что репозитори, что фс оркеструются апликейшн слоем. Единственный нюанс это то, что репозитории знают о доменной модели, и возможно поэтому их относят к доменному слою. А если фс будет выполнять специфичные для доменной модели операции, то интерфейс фс тоже можно отнести к доменному слою?
В общем что куда относится?
Вот интерфейсы репозиториев относят к доменному слою, даже не смотря на то, что доменная модель не должна знать хранится ли где-то ее стейт.
А если это интерфейс для работы с файловой системой, то куда его? Кажется, что к апликейшн слою.
Но, что репозитори, что фс оркеструются апликейшн слоем. Единственный нюанс это то, что репозитории знают о доменной модели, и возможно поэтому их относят к доменному слою. А если фс будет выполнять специфичные для доменной модели операции, то интерфейс фс тоже можно отнести к доменному слою?
В общем что куда относится?
SP
А какая разница?
Ориентируйся на принцип стабильных зависимостей
Ориентируйся на принцип стабильных зависимостей
A
Ну удобно с точки зрения организации кода
SP
Что именно удобно? Почему? Мне удобно без папок
A
Мне удобно когда есть папки для слоев и мб еще какое-то деление внутри них. Так понятнее что от чего изолировать и какой код смотреть
SP
если понятно что от чего изолировать - откуда вопросы куда положить что? значит не понятно. значит надо разобраться что мы от чего хотим отделить и почему
A
так я же это и спроосил
SP
условно, зачем нам разделение на application layer и domain layer? application layer все еще не является инфраструктурой а значит реализации ни репозиториев ни штук для доступа к файловой системе мы туда класть не можем.
SP
куда класть интерфейсы - идеально рядом с тем что эти интерфейсы юзает или выделяем в третий модуль (инверсия зависимостей)
AI
Все зависит от того, что этот интерфейс фс делает
Если там абстракция аля get/find order, то можно и в домен, если там saveFile, то, очевидно, в домен нельзя
Поинт в том, что если это чисто инфраструктурная штука, то и место её там. А так все верно сказали, смотри на стабильность зависимостей
Если там абстракция аля get/find order, то можно и в домен, если там saveFile, то, очевидно, в домен нельзя
Поинт в том, что если это чисто инфраструктурная штука, то и место её там. А так все верно сказали, смотри на стабильность зависимостей
SP
мы всегда должны смотреть на отношения объектов а не на объекты в вакууме
SP
более того, может быть такое что в домене свой интерфейс, в аппликейшене свой но на уровне инфраструктуры это имплементит один адаптер какой
SP
есть масса вариантов, но основная идея - специализация интерфейсов под задачу (задача определяется клиентским кодом а не реализацией) и выставление зависимостей в сторону стабильности (штуки которые меняются часто должны зависеть от штук которые меняются редко, никто не должен зависеть от вещей которые меняются чаще себя, контракты можно делать стабильными если они специализированы)
SP
по факту все там принципы солиды и прочие правилы трех это "работает не трогай" и дизайн системы мы должны делать именно с этой мантрой. Ну или если сложнее выражаться "не допускать каскада изменений в системе", когда потрогав одну штуку придется править его зависимых другей, а потом и тех кто от них зависит и так идет каскад распускаются баги
SP
еще момент - я например вижу смысл вводить отдельный слой "аппликейшен" только и только для того что бы вводить жесткое правило - никакой логики в аппликейшен слое - вся логика делигируется зависимостям
SP
если таких ограничений нет - не особо есть смысл делать эту границу между апликейшеном и доменом - лучше сфокусироваться на разделении разных поддоменов