Отправьте их в принудительном порядке изучать материалы Курпатова. Может даже пусть в его академию сходят. Там им между делом объяснят что такое Факт Карта (она же продвинутый майнд меп). Хотя судя по тому что вы оперируете термином «интеллектуальный объект» — вы и сами знаете это.

Из своего опыта — хорошо помогает ГТД. Выгрузите все процессы во внешнюю систему, определите границы процессов(рабочие дни, выходные) и жить станет легче. Будете крепче спать без алкоголя.
Но с другой стороны, алкоголь, в ограниченных количествах, — это антидепрессант.
Так что иногда — это(алкоголь) меньшее зло. Но как вы уже поняли — по другим причинам.

Спасибо что проявили интерес.

Насколько я понял, Фасад существует, в первую очередь, для инициализации приложения. И это фасад к фреймворку, не к приложению. Так в нем собраны методы для регистрации комманд, медиаторов и модели. Так разработчику проще инициализировать приложение. Не надо копаться во внутренностях самого фреймворка.

Вот пример от TodoMVC. Как видите здесь нет публичных методов как таковых, но используются методы фреймворка.

Вы уже применяли этот подход, поэтому хочу спросить, не запутывается ли логика в клубок из-за общение через фасад?

Т.к. фасад в логике самого приложения не участвует, то вся логика находится в командах. Команды группируются различными образами, можно положить несколько команд в команду-агрегат и т.п. Т.к. команды это отдельные классы, то и хранятся они в разных файлах(в AS3, Java). Соответственно не надо бегать особо по цепочке экшинов, а все наглядно дереве файлов в IDE.

Команд не может быть меньше чем логических действий в приложении + 1(StartUpCommand). По своей сути эти команды ближе к UseCase из Clean Architecture.

Разработчики React ведь сами позиционируют его как библиотеку и чисто View. Так что почему не использовать его так, как задумано? Плюсом мы получим Clean Architecture из коробки, ведь если над Реактом будет дополнительный слой, то там можно использовать Presenter, преобразовать все данные и оставить UI компоненты примитивными. А значит проще будет тестировать. Того же, в принципе, можно добиться c Redux. Только в качестве презентеров будут селекторы. Вы можете сами развить идею.

Безболезненно можно будет перейти на другую UI-библиотеку, но часто ли такой переход осуществляется?

Вот как раз таки в текущей ситуации, когда фреймворки обновляются каждый год, оно и надо.
Год назад мне достался проект на ангуляре 1.3. Рабочий бэкенд, не публичный. Конечно же все новые проекты у нас на Реакте. Переписать его весь и сразу — слишком много работы. А если мы поженились с фреймворком, и описали нашу логику в Реакт компонентах или Ангуляр компонентах, по надо именно что переписывать его целиком.
Слишком затратно и никто этого в здравом уме не будет делать.
При подходе PureMVC, я мог бы заменять UI компоненты по мере надобности. И выпилить ангуляр со временем.
Для бизнеса это значит, что не надо нанимать разработчиков для работы на супер старых версиях фремворков, которые никто уже не использует. И не надо раз в 2 года переписывать огромные проекты.
А для разработчиков — мы можем в разумных пределах пробовать новые библиотеки, заменять обратно не совместимые версии и т.п. Захотелось Vue — сделал страничку отдельную и никто не умер.

Мне недавно пришла идея, что «не все так однозначно» :)
Может ну его этот один стор и монолит?
Разные экраны — разные Реакт виджеты. У каждого свой стор. И не надо их смешивать.
В любом случае у фронтенд приложения нет базы данных, оно оперирует кэшами. База — она где-то в мускуле\динамо\монге\и тп. А кэши оптимизируются под конкретные нужды.
И это даже не противоречит идее единственного источника данных. Ведь для конкретного экрана — кэш действительно один. И даже лучше, это помогает с SRP и DDD. Ведь разные вещи остаются разными. И нет головной боли от того сколько полей где хранить.

Проехали. У каждого своя каша в голове. Давайте к конструктиву.

Мне вот например статья зашла. Пример пусть и простой, но похож на то, что я хочу сделать для своих проектов на реакте и когда-то давно делал для AS3 во флэше, и на джаве. А вот почему это мне нравится — это уже другой вопрос.

Я искренне уверен, что код я пишу для людей, а не для интерпретатора. Так что, я хочу чтобы он был прост и понятен любому новоприбывшему на проект. С редаксом так не выходит. А вот PureMVC — работает на ура. При том что оно существует ОЧЕНЬ давно. Реакта тогда и в помине небыло. И этот фреймворк решает проблему на всех платформах до сих пор. Это развитая идея того самого MVC, упомянутого автором статьи. Эта модель гораздо ближе человеку и легче понимается, чем эти все рекурсивные вызовы и потоки.

Другим ключевым моментом, для меня, является тестопригодность приложения.
PureMVC созданный черти знает когда, хорошо ложиться в описаную Р. Мартином «Чистую Архитектуру». По сути просто имплементирует DiP.
А это значит, что мне не надо тащить в проект дополнительно 3-5 сложных фреймворка, чтобы протестировать все. Достаточно будет простого xunit фреймворка.

И я рад спросить совета у Деда Васи, который не только жигули чинил, а чинит сейчас новейшие Теслы. Ведь он не замкнут на реакте их 80х, а пробует и берется за все стоящее сегодня, с оглядкой на прошлое.

Не надо принижать достоинство и авторитет старшего поколения. Те люди, у которых надо учиться — успешно выполняют вашу работу и сейчас. А опыта у них на лет на 20 больше.

Редукс тащат всюду по тому, что об этом только хабр и поет. В том смысле, что актуальные новости на IT ресурсах — они именно про то что сейчас актуально. А проблема MVC была актуальна 20-30 лет назад. Новички смотрят главную страницу хаба, а там про MVC ни слова. Большая часть этих молодых людей в тематических вузах не училась, фундаментальных знаний не получала. Хорошие книжки слишком толстые, люди боятся их. А в тонких — ничего нет.
Старшим не верят.

Про «фронты» можно долго беседовать, но это из разряда холиваров. Я не верю что можно переубедить кого-либо в этой битве написав коммент. А стереотипы не на пустом месте рождаются.

Кто не помнит своего прошлого, обречен пережить его вновь.
— Джордж Сантаяна

Я наблюдаю именно то что вы описали. А вы говорите то же что и Дядька Боб.

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

Вот что точно не профессионально — игнорировать опыт старших коллег(по опыту) и самонадеянно пилить свои велосипеды

Спасибо за статью. Согласен с автором, про необоснованную сложность редукса. Уже года полтора пытаюсь донести до наших фронтедщиков, что это зло во плоти. Да времени небыло запилить хороший контр пример.
Хотел уточнить, в примерах, вы специально упростили, слив вместе контроллер и вью? Рассматриваете ли вы подход из PureMVC как более правильный? Где реакт компоненты будут играть роль именно UI компонентов и предоставлять апи, а над ними будет слой ViewController'ов?

Верно подмечено.
Хотелось бы еще добавить, что контейнеры это классно, но сейчас все стремятся в AWS Lambda / Google Functions. И с ними вся головная боль контейнеров — на совести провайдеров. И с затратами все норм. Ну а если без контейнеров никак, то у амазона, например есть сервис Fargate, который позволяет арендовать контейнер, а не ес2 инстанс, напрямую. Т.е. ECS без головной боли.
Так что все движется в правильном направлении.

Мне понравилось как SOLID разжевал Александр Бындю.
В свое время именно его примеры вызвали тот самый эффект «Ага! Вот оно как!». Может и вам подойдет, как референс для новичков?

Так в этом и прелесть абстракций. Вам не надо знать что именно вы будете использовать. Заглушка === Interface === Абстракция. Мне кажется вы все правильно поняли.

Другое дело, что не все абстракции одинаково полезны.

Про ту же СУБД. Мы можем ввести абстракцию TableGateway или Repository. Обе они прячут имплементацию БД. Но первая, скорее всего, треснет, как только надо будет поменять тип хранилища с реляционого на ключ-значение. Но никаких проблем в смене MySQL на другую SQL базу не возникнет. А Repository будет жить даже в любом случае, но нужен ли он в приложении — другой вопрос.

Ну а по поводу потратить время\деньги — нет ничего хуже, чем проигнорировать процесс сбора требований. Если не изучать вопрос хоть как-нибудь, вы рискуете потратить гораздо больше, чем потратили бы на ресерч.

В том то и дело, что следование этим принципам минимизирует такие работы. Достаточно будет переписать низкоуровневые классы доступа в БД. При этом бизнес логика и логика самого приложения будут не затронуты.

А по поводу 3-го пункта — так надо иногда делать, ибо выбранная в начале пути технология может не обеспечить удовлетворения новых требований, предъявляемых проекту. Если этого не сделать — вы просто навредите проекту.

Технологии не приколачиваются гвоздями к решению.

Спасибо за статью.
Всегда интересно посмотреть как это делают другие разработчики.

Мы решили полностью следовать советам книги Patterns, Principles, and Practices of Domain-Driven Design. Тут подробно описано, с примерами, что зачем и почему, куда что класть.
Все то что Эванс говорил, но разжевано.

У меня так же есть несколько вопросов по примерам:

Обоснуйте пожалуйста, почему метод Accept принадлежит сущности Company. Ведь аккредитация выдается Ведомством. А то получается что компания сама себя куда хочешь может аккредетировать… Ну или как минимум в этот метод должен передаваться Policy ведомства или экземпляр объекта Аккредитация, с данными кто выдал и почему.

Почему метод DangerouslyChangeInnAndKpp вообще содержит в себе эту приставку? Если предметной области это нормальное явление — это бессмысленно. Может стоило тогда ввести другую сущность?

Я не знаком с .Net вообще, но вы упоминаете «луковую» и «чистую» архитектуры, а потом в домене используете public class Specs. Разве это не кусок вашего фреймворка только что просочился в домен? Т.о. вы нарушаете направление связей.

Тех кто понимают, что в коде проблема — не надо уже учить, сами знают что делать. А те кого надо учить — не понимают, им надо показать и рассказать.
Перевести из «не осознанной некомпетентности» в «осознанную»

sergeykorol.ru/blog/competence

Поддерживаю! Это как чистописание. Прописи для программистов.
Вот только у школ и вузов другая задача стоит.
Школы учат азам, там нет задачи из каждого сделать программиста.
А в вузах все всегда на одноразовых задачках. Преподаватели обычно горе-теоретики, так что скорее всего и код не читают. Главное чтоб работало. А это не способствует развитию хорошего стиля кода/архитектуры. Теоретически это можно автоматизировать сбором метрик, но кто там заморачиваться будет?

Та же ситуация в веб студиях — там проект делается левой ногой на выброс, никто там долго поддерживать его не собирается.

По этому там недостаточно боли от плохого кода. Тесты не пишутся. Призрак архитектуры унаследованный от фреймворка.

Только в компании разрабатывающей свой продукт или там где ценится качество(принципиально), люди могут дойти до осознания что надо что-то менять.
К сожалению, если это дойдет до одного, но он не сможет объяснить другим — все пропало.

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

Желательно при этом сделать это на примере JS UI приложения. Ибо имхо это самый большой пласт начинающих разрабов.

Мне пришлось приложить не мало усилий, чтобы мои коллеги осознали, что надо учиться и начали хотя бы статьи читать. Мне повезло с техлидом. Обычно народ боится брать толстую книжку в руки ) А толковая литература обычно 300-1к страниц.
Так что сомневаюсь что они вот так сразу, не дочитав статью, а скорее всего они ее не дочитали, рванули читать что-то :)