Реализация SOLID и слоистой архитектуры в Node.js с TypeScript и InversifyJS

[@funca]

Интерфейс AircraftRepository является частью доменных сервисов, в то время, как AircraftController и реализация AircraftRepository, являются частями инфраструктурного слоя

Интерфейс AircraftRepository является контрактом между контроллером (высокоуровневой частью) и репозиторием (низкоуровневой частью). Поэтому размещение интерфейса в нижних слоях будет нарушать DIP, т.к. у контроллера появляется зависимость в обратном направлении.

Dependency Inversion Principle говорит нам о том, что модули верхнего уровня не должны зависеть от модулей нижних уровней, оба должны зависеть от абстракций. Это нужно для возможности менять низкоуровневые части, не затрагивая компоненты более высокого уровня. Если с деталями реализации все более-менее понятно, то размещение абстракций по слоям часто вызывает вопросы.

Идея примерно в следующем. Допустим вы организация (высокоуровневая часть, клиент), которая выбирает исполнителя (низкоуровневую часть). Пусть вашим исполнителем будет клининговая компания. Выбрав какую-то одну из них вы собираетесь заключить договор. Есть два варианта два:

1. Прямой — подписать стандартный договор клининговой компании (контракт низкоуровневой стороны). Недостатком является то, что принимая чужие условия, вы будете вынуждены как-то под них прогнуться. Это привязывает вас к особенностям оказания услуг конкретного исполнителя. В случае проблем, заменить исполнителя на другого быстро не получиться, т.к. вы уже подстроились под условия текущего, и будете вынуждены перестраиваться под условия нового.

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

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

[@alexanderlapygin]

Блестящая метафора для DIP, спасибо!

[@VanquisherWinbringer]

Хм, почитайте

1. enterprisecraftsmanship.com/posts/domain-vs-application-services
2. www.ozon.ru/context/detail/id/147927649

Если кратко: Repository и IRepository оба часть Infrastructure.
Там же даже пример есть типичного DomainService чтобы всем было понятно что это такое и что в БД он лезть в принципе не должен. Да даже IRepository ему использовать нельзя. Его может только ApplicationService вызывать и все что выше него.

public sealed class AtmService // Domain service
{
    public decimal DispenseAndCalculateCommission(Atm atm, decimal amount)
    {
        atm.DispenseMoney(amount);
        return atm.CalculateAmountWithCommission(amount);
    }
}

Вообще DomainService это Validator, Calculator и прочее в этом роде. Принимает какие-то значения и возвращает результат вычисления. В ФП DomainService это чистые функции не работающие с IO ну а Entities это типы (и в ФП всякие User есть). Правильнее будет IRepository поместить в ApplicationService рядом с IUserSerivice и UserService.

[@p0vidl0]

Резонно. Спасибо за комментарий и полезные сслыки.

[@VanquisherWinbringer]

Это вам спасибо. Вы таки вдохновили меня написать статью habr.com/ru/post/501206

[@RiverFlow]

ООП архитектуры это всегда про сферические догмы и египетские казни всем кто их ослушался, потому что ты пишешь код «на века» и твои потомки никогда не напишут своего а будут поколениями рефакторить и расширять твой солид — своим!

Я вообще не буду писать никаких классов, я тупо напишу процедуру рисования кружочка который легко разложится на вектор или пикселы любой другой процедурой и пересоберется в черта лысого — третьей, что и бывает нужно в 99% случаев реального использования.

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

Хотя если вашему овнеру некуда девать бабло — то бесконечный рефакторинг это золотая жила!