Хм... це спрощує використання типізації, але руйнує її суть.

Опис вхідних і вихідних параметрів функції формує контракт цієї функції. Тобто — потрібно передати 2 числа, і функція поверне число. Якщо хтось захоче повертати щось інше ніж число — йому потрібно буде свідомо змінити контракт. Для спрощення можете це розглядати як unit тест на мінімалках.
Це спрощує життя розробникам, особливо на великих проектах де «легкість підтримки проекту» досить важливий критерій.

Тому використовувати «Type Inference» всюди і завжди я б не радив. Це інструмент і має використовуватись там де від нього буде користь. Якщо задача зробити швидко, а не якісно (при чому я не вкладаю негативного контексту сюди), тоді звісно конвенція по викорстанню «Type Inference» може зменшити час розробки з збереженням мінімально-задовільної перевірки типів. Але на середніх і великих проектах... я б все ж розрізняв випадки коли контрактами можна нехтувати, і коли не варто.

XD
то є трішки очевидно, чому ця приписка тут)))
я ж раджу увагу приділити самій статті)

дякую за відгук)

2. Ага, Ви продублювали мою строку з конструктором )
Замість типу передали як значення для створення інстанса — ключ. Тобто при створенні інстанса залежнсоті ви будете руками присвоювати відповідність цього інстанса і ключа. Що б робити це автоматично — потрібно посилатись на конкретну реалізацію)
І так як в 99% в додатку немає сильно розгалудженої системи залежностей, тому автоматичне створення оних є виправданим)

4. У випадку з DI це буде хоча б болісно, а на ревью палевно. Я кажу не про униможлпивнення, а про зменшення ризиків)

1. Згоден. Втім ООП в своєму розвитку пішло на дві голови далі функціонального підходу (не кажучи вже про процедурний підхід). Може це і смаковщина, втім на мій погляд функціональний підхі дуже розробника обмежує в побудові хоч скільки небуть масштабних рішень... я б мабуть його використовував лише для MVP... і то не всякого)

2. Тому що DI як інструмент предназначений для імпорту конкретної реалізації. Відразу з декількох причин:
— Якщо ми знаходимось в классі, умовно ProductController і ми хочемо реалізувати метод SaveProduct, тоді нам потрібно в конструктор класса проін’єктити залежність ProductMapper з транспортного шару. І ми не можемо ін’єктити умовний IMapper, тому що ми маємо бути впевнені що використовуємо. Для цього DI створюється в першу чергу. Втім якщо хочется посилатись на абстракцію — можна ін’єктити не за типом, а за ключем, тоді тип можна вказати будь-який. Для прикладу constructor(@Prop(’logger’) logger: ILogger). Але логгер доведетсья сетити в DIContainer самостійно.
— Ми можемо приймати одразу перелік необхідних классів з однієї абстракції. Для прикладу ми можемо приймати ProductMapper і UserMapper в одному ProductController. Якщо їх по-замовчуванню позначати як IMapper тоді явно виникне конфлікт...
— По-замовчуванню DI намагається по типу розрулити що саме ін’єктити. В статті є приклад, який показує цей процесс. Тобто якщо скормити DI не конкретний тип, а абстракцію — він просто не буде знати який тип створювати для контейнера. Як я писав вище, для таких випадків можна юзати ключі)

4. Ось. Тому коли реорганізовую структуру проекту, я в першу чергу хочу зробити так що б у ревьювера код ломаючий систему прям червоним світився і меготів. А у того хто хоче зламати систему на це пішло максимум зусиль і потрібно було спотиктись і розбивати лоба в кожному наступному файлі)

Трішки заздрю)
в PHP фреймворки хоч якусь структуру проекта задають. На клієнті це просто жах. Тупо mvvm паттерн + якесь flux-based solution і все. А потім кажуть що фронтенд не надійний((

Дозвольте спарирувати:

1. Імхо: організація бізнес-логіки застосунку повинна бути фреймворк-агностік. Якщо ваша бізнес-логіка знаходиться вся в компонентах та\або підв’язана під інструменти фреймворку, є велики різики з супроводженням проекту, не кажучи вже про неконтрольований ріст складності проекту з часом.
2. DI на ін’єкції не конкретної реалізації, а інтерфейсу, мабуть, не існує в природі. Або ж прошу жбурнути в мене посиланням на подібну реалізацію)
Одне діло якщо це агрегація классів, тоді так, ми можемо використовувати інтерфейси для отримання всіх переваг поліморфізму (саме так працює паттерн «стратегія»), втім коли ми ін’єктимо залежність в конкретний класс — ми очікуємо конкретну реалізацію.
3. Ангуляр з коробки пропонує дуже простеньку структуру яка складається з компонентів і сервісів, а все інше треба допилювати окремо. Тому як все буде організовано — лише Вам вирішувати)
4. Я катигорично не погоджуюсь що архітектура це набір правил на папері. Архітектура повинна бути закладена в коді. Якщо є прошарки — потрібно забезпечити неможливість їх некорректного застосування. Якщо є модулі — потрібно змусити створювати для них фасад і окремо його реєструвати. Архітектура додатку повинна бути максимально самодостатньою, без необхідності вичитувати мануали на конфлюєнсі. Імхо)

Ухх... коли згадали за zend я аж прослизився)
згадалось прям

Ця фраза підкреслювала важливість описання структури проекта таким чином, що б максимально зменишити можливість її порушення.
Щодо того наскільки саме описана ситуація реалістична... ну досить реалістична. Я не знаю що Ви мали на увазі під «помилкою», але якщо код працює і існує в проекті, значить він може бути скопіпащений.
Таким чином те що раніше було заборонено конвенціями спочатку може стати «пропущенною помилкою», потім «виклюенням з правил», а в решті решт «нормальною практикою». Саме тому структура проекту має максимально ставити палки в колеса тим хто вирішив її ламати. Що б її ламання було максимально очевидним на ревью, що б у всіх виникло відчуття «тут щось не так».

P.S.
Часто пофіксити в коді 9-ної давнини — це дуже дорого. З великим імпактом на проект, що потребуватиме додаткових QA ресурсів... то ж не завжди є така можливість, одразу щось виправити)

Дуже дякую за розгорнуту відповідь!)

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

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

Ще раз дякую за відповідь))

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

Щодо Вашого рішення з модулями. Не скажу що зрозумів його на 100%, втім якщо ви можете контролювати використання експорту в різних прошарках — тобі це рішення може для Вас спрацювати (до прикладу, якщо Ви можете заборонити використання файлів транспортного прошарку в ui компонентах) Рішень багато, кожен обирає собі те що йому підходить)

Втім є декілька тонкощів в ідеї з імпортами на які я б звернув увагу:
— ідея зберігати всі константи в одній дерикторії є не дуже файною. Краще їх зберігати поряд с місцем використання, або в модулі який відповідає за відповідний домен. Просто виносити всі типи, константи, фабрики в окремі файли, це те саме що зараз виносити всі css, html и js файли в різни дерикторії, а потім намагатись імпортувати їх в відповідні компоненти)
— якщо весь контроль за імпортами буде триматись на єдиному лінтері — є ризики що його будуть обходити. Бо це легко. І з зростанням кількості таких обходів є ризик що правило вимкнуть зовсім. Такі ризики є і з DI, але DI, як на мене, більш наявно описує взаємозв’язок між прошарками.

P.S.
Я б дуже хотів побачити лістинг проекту з імплементацією Вашої ідеї )

Влучно підмічено)
Втім просту «структуру директорій» багато хто називає «архітектурою»)

Цікавить яким чином з конфігу будуть вимикатись модулі. Тобто я ± розумію принцип відключення, але... для прикладу є модуль умовно «продукт», якщо його вимкнути тоді зникнуть сторінки «продукт», «каталог» і інші. Весь обслуговуючий фунціонал буде не потрібен, тому це також ок. Але як бути з модулями які містили модуль «продукт» як залежність?
Потрібно або і їх автоматично відключати, що певно не дуже хочется, або розділити інтерфейс кожного модуля по принципу NullObject що б додаток все ще міг до нього звертатись, але не отримував реальних данних. Виглядає як дуже не проста задача по менеджменту залежностей і підтримці працездатності проекту при їх відключенні...
Хоча можу припустити що під якийсь специфічний домен таке рішення буде значно легше реалізовувати. Для прикладу якщо всі модулі легко можуть буди незалежні один від одного.

То ж, підсумовуючи:
— яким чином будете забезпечувати безпечне відключення\підключення модулів?
— чи є Ваше рішення універсальним, тобто таким яке можна перевикористати на більшості проектів?

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

Хмм

В голові були думки про потік данних, коли малював діаграму... але Ви праві, потрібно буде ту стрілочку розвернути трішки XD

Прибрав дублювання, дякую що помітили)

Хмм.. можливо на вихідних додам в кінці таких прикладів, дякую за пораду)

Дяка)

Скоро просунемо nodejs на бек, і на беку також все стане просто XD

Дякую автору за статтю. Дійсно підхід розшарування проекту являється правильним вектором, втім дозвольте додати декілька коментарів які стосуються деталей реалізації:
1. В статті зазначалось питання композиції шарів, але я б хотів звернути увагу на їх ізольованості. Скажімо я б хотів з шару StateLayer викликати шар ServiceLayer, що мені завадить це зробити? Сподіваюсь відповіддю буде не «код ревью», і сподіваюсь в наступній статті автор трішки зачепить цю тему, і можливо, навіть, з використанням IoC.
2. Чи варто виносити «утіліти» в окремий шар? Як було зазначено вони — просто шматки чистих функцій які можуть знадобитись будь-де на проекті. Враховуючи їх... глобальність, чи варто взагалі до них відноситись як до шару накладаючи додаткову когнитивну складність для розуміння цих фунцій? P.S. якщо програміст створює хелпер — значить десь на проекті є косяк. Бо навіть функції форматування дати можна знайти краще місце)
3. В статті описаний дуже архаічний погляд на роботу з стором, особливо в контексті vue3. Я обожнюю те як автор пропонує працювати зі стором, але реалії такі що від такого підходу багато хто вже давно відмовився і тенденція іде саме в цю сторону. Ну і знову, якщо брати чистий redux або flux, то там архітектурно закладені обмеження які не дадуть напряму мутувати стору... у vue в цьому плані все куди гірше ((
4. З того що очікував, але не побачив — якийсь middleware прошарок для опису бізнес-логіки. Тобто ось потрібно нам оновити сторінку з продуктами на якій є пошук, фільтри і інше. До того ж є бізнес-правило що фільтрувати продукти можна лише тоді коли луна знаходиться в 3ій фазі. І ось куди запхнути код який формує payload для запиту і описує бізнес-правило? В action? Не дай боже, але кудись в utils? Залишити в компоненті? Як на мене всі перераховані варіанти погані, але в статті я не знайшов опису альтернативи, і сподіваюсь автор наступного разу також зверне на це увагу)

Тобто я говорив за аттребути загалом, як перелік якостей, а не за якісь конкретні)

Якщо ми говоримо за фронтенд, то я дуже легко можу уявити як мануальщики пропустили який рідкий випадок і на проді n користувачів зловить бажину типу «can’t get name from undefined». І ось зробити так що б ця бажина не поклала апку — досить доцільно, адже навіть на 100% (утопія) покритий тестами проект не гарантує що таке не трапиться на проді )

Втім якщо овнер вважає що краще найняти n розробників для мануального парсингу лгів — для мене це був би червоний флаг для відкриття свого резюме на джинни))))

Але про овнерів і манагерів в 2ій частинні статті, сподіваюсь скоро вийде ))

Так, я їх обрав для прикладу і тільки. Кожен розробник має вирішувати що для проекту пріоритетне, а чим можна пожертвувати.

Мабуть варто цю фразу «для прикладу» додати в статтю )

Доречі також кейс)))

Були в моїй кар’єрі проекти які просто залишали помирати на «підтримці» доки вони приносять дохід, з розумінням що відрефакторити неможливо, а вдосконалювати — задорого )