а чому ви вважаєте, що СОЛІД це інфоциганщина? Як на мене і те і інше — все важливо

Да без питань, ось.

Принцип інверсії залежностей (DIP) є фундаментом для сучасних архітектур, і хоча суть залишається незмінною (залежність від абстракцій, а не від деталей), механіка його застосування в цих архітектурах має свої акценти.

1. N-Layered Architecture (Багатошарова архітектура)
У класичній 3-рівневій архітектурі (Presentation -> Business Logic -> Data Access) верхні шари зазвичай залежать від нижніх, що створює жорстку зв’язність і заважає тестуванню.

Без DIP: Бізнес-логіка знає про базу даних. Клас OrderService (з Business Logic) безпосередньо створює SqlOrderRepository (з Data Access). Із DIP: Ми інвертуємо цю залежність. Шар бізнес-логіки стає «головним», і він диктує правила через абстракції.

Приклад:
У шарі Business Logic (BLL) ми створюємо інтерфейс IOrderRepository. Тут же діє наш OrderService, який приймає цей інтерфейс через конструктор. Дізнавшись лише про абстракцію, BLL нічого не знає про SQL чи Entity Framework.
Шар Data Access (DAL) тепер посилається на шар BLL! Він містить клас SqlOrderRepository, який реалізує інтерфейс IOrderRepository.
Отже, залежність інвертувалася: інфраструктура (DAL) залежить від абстракцій бізнес-логіки (BLL).

2. Onion Architecture (Цибулева архітектура)
Головне правило Onion: всі залежності спрямовані строго всередину, до центру (Домену). Жодних винятків.

Проблема: Як домену дізнатися дані з бази або відправити email, якщо він не має права знати про зовнішній світ? Застосування DIP: Центр (Domain/Application Services) використовує DIP, щоб визначити «контракти» для всього світу. Зовнішні шари слухняно їх виконують.

Приклад:
Шар Domain (Core): Оголошує інтерфейс сповіщень INotificationService та логіку, яка його викликає при певних подіях у домені.
Шар Infrastructure (найбільш зовнішній шар): Містить класи SmtpNotificationService або TelegramNotificationService, які реалізують інтерфейс INotificationService (визначений у Домені).
На відміну від N-Layered, де DIP часто обмежували лише рівнем DAL, в Onion DIP є життєво необхідним для всіх зовнішніх комунікацій (брокери повідомлень, кеші, API, БД).

3. Clean Architecture (Чиста архітектура)
Чиста архітектура концептуально дуже схожа на Onion (і Гексагональну). Однак Роберт Мартін робить сильний акцент на використанні DIP для правильного формування потоку управління (Flow of Control) між шарами через так звані «порти» та «адаптери».

Застосування DIP: Він використовується не лише для того, щоб сховати базу даних, а й для того, щоб розв’язати Use Cases (сценарії використання) з тим, як дані подаються (Presentation).

Приклад (DIP для вихідного порту — Output Port): Уявімо потік: Controller викликає UseCase, а результат треба віддати Presenter’у, щоб той сформував JSON для клієнта. За правилом Clean Architecture UseCase знаходиться глибше, ніж Presenter, тому не може від нього залежати.
Шар Use Cases (Application Business Rules): Створює абстракцію — інтерфейс IOrderOutputPort. Після виконання бізнес-логіки, UseCase викликає метод цього інтерфейсу (наприклад, port.Success(order)).
Шар Interface Adapters: Клас OrderPresenter (який форматує дані для вебу) реалізує інтерфейс IOrderOutputPort.
Результат ретельного використання DIP: Потік виконання йде від Controller -> UseCase -> Presenter. Але завдяки інтерфейсу IOrderOutputPort, математична залежність направлена від Presenter -> UseCase. Ми інвертували залежність щодо потоку виконання.

Короткий підсумок:

— У N-Layered DIP рятує бізнес-логіку від «прибивання цвяхами» до конкретної бази даних технології (DAL залежить від BLL).
— В Onion DIP — це єдиний спосіб дотримуватися правила «всі залежності йдуть до центру», захищаючи Домен від будь-якої інфраструктури.
— У Clean Architecture DIP (через Input/Output Ports) додатково дозволяє Use Cases залишатися незалежними від деталей фреймворків, інтерфейсу користувача (UI) та форматів відповідей.

Гм. Може варто прочитати її? Що саме не зрозуміло?

Стаття не про DI (Dependency Injection) а про DIP(Dependency Invertion Principle).

Ох, лишенько, Ви вирішили зі мною помірятися статевими ознаками?
Ну давайте. Я почав керувати розробниками в 98 році. В 2001 я був керівником відділу веб-розробки Ліга-нет. В 2004 я був першим архитектором в Люксофті, але потім перейшов в тімліди. Потім я був РМом (але насправді тімлідом в Сіклум) а потім в богатьох компаніях до 2016 року. А потім я випустив тисячі розробників по моїм курсам по архітектури додатків і зараз ще по курсу тімлідства. Відгуки можете подивитися або тут на ДОУ, чи на гугл май бізнес. Також я є співвласником софтверної компанії. Кожен день спілкуюсь з розробниками. Автор безлічі статей та відео. Тепер мені цікаво — можна почитати ваші статті? Чи послухати ваші виступи? ну щоб оцінити ваш рівень? А то останні 7 років ви наче підприємець, звідки ви знаєте розробників? Ну і ваш напрям реверс інжінірінг викликає сумніви.
Якщо ж хочете конструктивного спілкування, давайте краще перейдемо на нього. Наче доросла людина

це як раз приклад того, що буває, коли керівник не вміє делегувати. а просто скидає на людину завдання, яке занадто для неї складне

Це одна із найпоширенейших пасток, куди потрапляють більше 90% тімлідів, я про неї на першому занятті розповідаю. Ні, це не вірно, а навпаки змушує вас перепрацьовувати та вигорати

проблема тут в тому, що замість того, щоб рівномірно розподілити завдання між співробітниками ви все тягнете на собі. І звісно це не можна просто скинути на людину, яка цього не вміє, треба вести людину по рівням делегування. Коротше, зараз буду вам половину курсу переказувати :)

дивиться, ви зробили половину шляху до висновку. Окей, некваліфікований джун не потрібен, тому що він робить все не так. Окей, а далі? Мабуть треба його навчити? Щоб ваша команда (так, за допомогою ШІ, звісно) працювала набагато швидше, ніж тільки ви сам плюс сеньори? Ну і наступний крок — мабуть джунами треба керувати? Мабуть треба їм делегувати вірно, а не просто скидати їм задачі, які вони не потягнуть? Ну власно про це і стаття

дякую за підтримку :) Ну і якщо хочете дізнатися Як це робити, приходьте на курс, розповім

а це смішно :)

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

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

ахаха, мені приємно :). Ну мабуть з ютубу? або з конференцій, я багато де виступаю:)

Дякую, дуже приємно :)

Такий і був план :) Треба напевно написати ще чому насправді якщо ти хочеш бути найкращим програмістом, то треба обирати саме напрям тімліду, а не архітектора. Але це буде вибух :))

це просто значить, що хтось із дорослих бере на себе відповідальність керувати на ніжному рівні, тому що без цього нічого не працює.

ок. суржик — наше все :)

Гм. жодного разу таке не бачив. Мабуть у вас просто хтось взяв на себе відповідальність і насправді виконував обов’язки ліда? Зазвичай саме так. Інакше — хаос.

я працював в такої команді. Можу багато розповісти і поганого, але достатньо результату — компанія розорилася