Не надо никаких колонок Ready For Test и Test. Это противоречит принципам XP и CD. Все сценарии использования должны быть описаны до начала работы. Если что-то забыли - ничего страшного, пошли к разработчику и добавили вместе - колонки In Progress достаточно для этого. И не надо играть в пинг-понг передавая задачу от разработчика тестировщику.
Предлагаю автору ознакомится с творчеством Dave Farley на YouTube(канал ContinuousDelivery). Особенно полезным может оказаться его лекция Acceptance Testing for Continuous Delivery by Dave Farley #AgileIndia2019
И с книгой The Principles of Product Development Flow: Second Generation Lean Product Development и азами XP, чтобы не плодить ненужные роли, очереди на доске и не вводить компанию в болото.
Отправьте их в принудительном порядке изучать материалы Курпатова. Может даже пусть в его академию сходят. Там им между делом объяснят что такое Факт Карта (она же продвинутый майнд меп). Хотя судя по тому что вы оперируете термином «интеллектуальный объект» — вы и сами знаете это.
Из своего опыта — хорошо помогает ГТД. Выгрузите все процессы во внешнюю систему, определите границы процессов(рабочие дни, выходные) и жить станет легче. Будете крепче спать без алкоголя.
Но с другой стороны, алкоголь, в ограниченных количествах, — это антидепрессант.
Так что иногда — это(алкоголь) меньшее зло. Но как вы уже поняли — по другим причинам.
Насколько я понял, Фасад существует, в первую очередь, для инициализации приложения. И это фасад к фреймворку, не к приложению. Так в нем собраны методы для регистрации комманд, медиаторов и модели. Так разработчику проще инициализировать приложение. Не надо копаться во внутренностях самого фреймворка.
Вот пример от 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-го пункта — так надо иногда делать, ибо выбранная в начале пути технология может не обеспечить удовлетворения новых требований, предъявляемых проекту. Если этого не сделать — вы просто навредите проекту.
У меня так же есть несколько вопросов по примерам:
Обоснуйте пожалуйста, почему метод Accept принадлежит сущности Company. Ведь аккредитация выдается Ведомством. А то получается что компания сама себя куда хочешь может аккредетировать… Ну или как минимум в этот метод должен передаваться Policy ведомства или экземпляр объекта Аккредитация, с данными кто выдал и почему.
Почему метод DangerouslyChangeInnAndKpp вообще содержит в себе эту приставку? Если предметной области это нормальное явление — это бессмысленно. Может стоило тогда ввести другую сущность?
Я не знаком с .Net вообще, но вы упоминаете «луковую» и «чистую» архитектуры, а потом в домене используете public class Specs. Разве это не кусок вашего фреймворка только что просочился в домен? Т.о. вы нарушаете направление связей.
Тех кто понимают, что в коде проблема — не надо уже учить, сами знают что делать. А те кого надо учить — не понимают, им надо показать и рассказать.
Перевести из «не осознанной некомпетентности» в «осознанную»
Поддерживаю! Это как чистописание. Прописи для программистов.
Вот только у школ и вузов другая задача стоит.
Школы учат азам, там нет задачи из каждого сделать программиста.
А в вузах все всегда на одноразовых задачках. Преподаватели обычно горе-теоретики, так что скорее всего и код не читают. Главное чтоб работало. А это не способствует развитию хорошего стиля кода/архитектуры. Теоретически это можно автоматизировать сбором метрик, но кто там заморачиваться будет?
Та же ситуация в веб студиях — там проект делается левой ногой на выброс, никто там долго поддерживать его не собирается.
По этому там недостаточно боли от плохого кода. Тесты не пишутся. Призрак архитектуры унаследованный от фреймворка.
Только в компании разрабатывающей свой продукт или там где ценится качество(принципиально), люди могут дойти до осознания что надо что-то менять.
К сожалению, если это дойдет до одного, но он не сможет объяснить другим — все пропало.
Под разжевывать — я предлагаю рассказать про все эти принципы на примере рефакторинга какого-либо типового проекта. Но чтоб там изначально была боль, которую народ не понимает. Рассказать как это влияет на эволюцию проекта, с примерами, как это лечится. Пошагово, вводя принципы и практики по одной. Чтоб новички увидели что-то знакомое, поняли что не так с этим и научились как делать хорошо.
Желательно при этом сделать это на примере JS UI приложения. Ибо имхо это самый большой пласт начинающих разрабов.
Мне пришлось приложить не мало усилий, чтобы мои коллеги осознали, что надо учиться и начали хотя бы статьи читать. Мне повезло с техлидом. Обычно народ боится брать толстую книжку в руки ) А толковая литература обычно 300-1к страниц.
Так что сомневаюсь что они вот так сразу, не дочитав статью, а скорее всего они ее не дочитали, рванули читать что-то :)
Обратите внимание на кол-во комментариев к статье. Все ведь по делу написано, но никто из новичков не задает уточняющие вопросы. Они еще не понимают зачем это нужно. Зато с удовольствием посмакуют новый плагин к реакту. Так что формат статей нужно менять. Надо разжевывать зачем это нужно. Чтоб и школьнику стало понятно.
Спасибо за перевод.
Идея статьи правильная, но, как обычно, в интернете кто-то не прав есть замечания.
В основном претензии к примерам. Так автор в статье говорит о SRP и Coupling, а потом в примере к SRP приводит код, который имеет не хилый такой Coupling, причем разных типов.
Возможно идея была в том, чтобы от раздела к разделу применять к коду описанные принципы. Но тогда стоило бы использовать один и тот же код и пошагово применять к нему их, а не приводить разные примеры.
Про сам каплинг, начал автор за здравие, закончил за упокой.
Только заголовок про каплинг, остальное все нужно удалить, дабы не создавать неправильное понимание у начинающих. Вот более правильный пример (первое что показал гугл) одного вида каплинга. Но есть и другие.
Интерфейсы методов — это не каплинг. Это документация для пользователя класса. Оно там для того чтобы можно было быстро понять как класс использовать. Когда автор заменил конструктор с явным обьявлением параметров на объект — он ухудшил «девелопер экспириенс». Теперь IDE не подскажет какие параметры ждет класс. А каплинг остался на месте. Если вдруг этому классу потребуется новый обязательный параметр в конструкторе — разработчику, все так же, придется лезть во все места где этот класс используется и добавлять его. Если вдруг какой-то параметр заменится, или поменяется его смысл — разработчику придется лезть и менять код во всех местах. Если параметр уберется — то код конечно будет работать, но разработчик открывший этот код, будет в замешательстве — «Что этот параметр значит? А не баг ли это?». Еще больше он обрадуется, когда в коде будет 2-3 разных вызова этого конструктора с разным набором параметров.
Чтобы решить эту проблему умные люди давным давно придумали паттерн Фабрика. Но просто заменить new Class на new ClassFactory — не достаточно. Надо таки разобраться что такое каплинг и принцип инверсии зависимостей. И передавать фабрику туда, где требуется создавать объекты.
Хотя есть правильный случай, когда объединение параметров в объект имеет смысл — это когда параметров больше 5 (зависит от соглашений в команде, основано на особенностях человеческого мозга держать в фокусе 5 +- 2 параметра). И то, тогда они объединяются не просто в объект, а в специальный класс, который проверит, что все параметры переданы и корректны.
Про связанность начиналось хорошо, но под конец просто бессмыслица. Хотелось бы обратить внимание на то, что повторяющийся код — это не всегда плохо. Есть разница между DRY и SRP.
В общем Cohesion и Coupling это очень важные метрики кода. И отличный показатель качества кода. Но материал в этой статье не дает хорошего понимания что это и как этим пользоваться. SOLID наше все.
Сначала мы не знаем ничего (Неосознанная Некомпетентность).
Читаем туториал. С абсолютной уверенностью, что мы делаем лучшую реализацию в мире, запиливаем это в проект.
Глаза горят, добавляем соседу в проект. Выделяем в пакет.
Потом, набив шишки в 2-3 проектах, идем искать ответы на новые вопросы.
Оказывается что проблем то не мало.
И тут мы понимаем что чего-то не знаем (Осознанная Некомпетентность).
Начинаем усиленно читать, смотреть конференции. Всеми путями получаем как можно больше знаний.
И когда познаем дзен — переходим в состояние Осознанной Компетенции.
Умеем использовать Репозитории, пилить CQRS и EventSourcing.
Видим правильные проблемы. И умеем их правильно решать.
Это естественный процесс. И очень длительный, если конечно у вас под рукой нет компетентного наставника.
Я не один проект написал с жирными репозиториями, пока научился этому.
Главное задавать как можно больше вопросов и искать ответы. Критически мыслить.
А зависимость от своего интерфейса лучше тем, что:
это наш интерфейс, и только мы можем его менять. Никакой сторонний пакет вдруг не скажет что метод депрекейтед или изменит порядок аргументов. Даже если что-то и поменяется — внутри нашего приложения ничего не изменится, т.к. мы только изменим имплементацию этого интерфейса а одном месте.
в интерфейсе будут только те методы, которые нам действительно нужны. Тогда когда мы заходим переехать с MySQL на NoSql — мы будем знать точно обьем работ.
это просто тестировать
NIH синдром — это если бы мы пилили действительно всю ОРМ с дата мепперами и юнит оф ворк. А с Репозиторием чаще всего получается как я описал в комменте выше. Т.е. затраты на поддержку === 0. Ведь мы по факту используем то что предоставляет фреймворк, просто внутрь нашего приложения не просочится инородный интерфейс.
Весь паттерн Репозиторий — это про интерфейс, а не про реализацию.
Верный вопрос и предложение. CQRS как раз об этом.
Только не надо добавлять методы с использующие SQL в репозиторий. Это совершенно другая зона ответственности. И назначение другое.
В целом тут на лицо не правильный подход к использованию Репозитория как паттерна. Отсюда и не верное и переусложненное решение.
Не надо никаких колонок Ready For Test и Test. Это противоречит принципам XP и CD. Все сценарии использования должны быть описаны до начала работы. Если что-то забыли - ничего страшного, пошли к разработчику и добавили вместе - колонки In Progress достаточно для этого. И не надо играть в пинг-понг передавая задачу от разработчика тестировщику.
Предлагаю автору ознакомится с творчеством Dave Farley на YouTube(канал ContinuousDelivery). Особенно полезным может оказаться его лекция Acceptance Testing for Continuous Delivery by Dave Farley #AgileIndia2019
И с книгой The Principles of Product Development Flow: Second Generation Lean Product Development и азами XP, чтобы не плодить ненужные роли, очереди на доске и не вводить компанию в болото.
Но с другой стороны, алкоголь, в ограниченных количествах, — это антидепрессант.
Так что иногда — это(алкоголь) меньшее зло. Но как вы уже поняли — по другим причинам.
Насколько я понял, Фасад существует, в первую очередь, для инициализации приложения. И это фасад к фреймворку, не к приложению. Так в нем собраны методы для регистрации комманд, медиаторов и модели. Так разработчику проще инициализировать приложение. Не надо копаться во внутренностях самого фреймворка.
Вот пример от TodoMVC. Как видите здесь нет публичных методов как таковых, но используются методы фреймворка.
Т.к. фасад в логике самого приложения не участвует, то вся логика находится в командах. Команды группируются различными образами, можно положить несколько команд в команду-агрегат и т.п. Т.к. команды это отдельные классы, то и хранятся они в разных файлах(в AS3, Java). Соответственно не надо бегать особо по цепочке экшинов, а все наглядно дереве файлов в IDE.
Команд не может быть меньше чем логических действий в приложении + 1(StartUpCommand). По своей сути эти команды ближе к UseCase из Clean Architecture.
Разработчики React ведь сами позиционируют его как библиотеку и чисто View. Так что почему не использовать его так, как задумано? Плюсом мы получим Clean Architecture из коробки, ведь если над Реактом будет дополнительный слой, то там можно использовать Presenter, преобразовать все данные и оставить UI компоненты примитивными. А значит проще будет тестировать. Того же, в принципе, можно добиться c Redux. Только в качестве презентеров будут селекторы. Вы можете сами развить идею.
Вот как раз таки в текущей ситуации, когда фреймворки обновляются каждый год, оно и надо.
Год назад мне достался проект на ангуляре 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 без головной боли.
Так что все движется в правильном направлении.
В свое время именно его примеры вызвали тот самый эффект «Ага! Вот оно как!». Может и вам подойдет, как референс для новичков?
Другое дело, что не все абстракции одинаково полезны.
Про ту же СУБД. Мы можем ввести абстракцию 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 приложения. Ибо имхо это самый большой пласт начинающих разрабов.
Так что сомневаюсь что они вот так сразу, не дочитав статью, а скорее всего они ее не дочитали, рванули читать что-то :)
Идея статьи правильная, но, как обычно, в
интернете кто-то не правесть замечания.В основном претензии к примерам. Так автор в статье говорит о SRP и Coupling, а потом в примере к SRP приводит код, который имеет не хилый такой Coupling, причем разных типов.
Возможно идея была в том, чтобы от раздела к разделу применять к коду описанные принципы. Но тогда стоило бы использовать один и тот же код и пошагово применять к нему их, а не приводить разные примеры.
Про сам каплинг, начал автор за здравие, закончил за упокой.
Только заголовок про каплинг, остальное все нужно удалить, дабы не создавать неправильное понимание у начинающих. Вот более правильный пример (первое что показал гугл) одного вида каплинга. Но есть и другие.
Интерфейсы методов — это не каплинг. Это документация для пользователя класса. Оно там для того чтобы можно было быстро понять как класс использовать. Когда автор заменил конструктор с явным обьявлением параметров на объект — он ухудшил «девелопер экспириенс». Теперь IDE не подскажет какие параметры ждет класс. А каплинг остался на месте. Если вдруг этому классу потребуется новый обязательный параметр в конструкторе — разработчику, все так же, придется лезть во все места где этот класс используется и добавлять его. Если вдруг какой-то параметр заменится, или поменяется его смысл — разработчику придется лезть и менять код во всех местах. Если параметр уберется — то код конечно будет работать, но разработчик открывший этот код, будет в замешательстве — «Что этот параметр значит? А не баг ли это?». Еще больше он обрадуется, когда в коде будет 2-3 разных вызова этого конструктора с разным набором параметров.
Чтобы решить эту проблему умные люди давным давно придумали паттерн Фабрика. Но просто заменить new Class на new ClassFactory — не достаточно. Надо таки разобраться что такое каплинг и принцип инверсии зависимостей. И передавать фабрику туда, где требуется создавать объекты.
Хотя есть правильный случай, когда объединение параметров в объект имеет смысл — это когда параметров больше 5 (зависит от соглашений в команде, основано на особенностях человеческого мозга держать в фокусе 5 +- 2 параметра). И то, тогда они объединяются не просто в объект, а в специальный класс, который проверит, что все параметры переданы и корректны.
Про связанность начиналось хорошо, но под конец просто бессмыслица. Хотелось бы обратить внимание на то, что повторяющийся код — это не всегда плохо. Есть разница между DRY и SRP.
В общем Cohesion и Coupling это очень важные метрики кода. И отличный показатель качества кода. Но материал в этой статье не дает хорошего понимания что это и как этим пользоваться. SOLID наше все.
Ну так и качается скил :)
Сначала мы не знаем ничего (Неосознанная Некомпетентность).
Читаем туториал. С абсолютной уверенностью, что мы делаем лучшую реализацию в мире, запиливаем это в проект.
Глаза горят, добавляем соседу в проект. Выделяем в пакет.
Потом, набив шишки в 2-3 проектах, идем искать ответы на новые вопросы.
Оказывается что проблем то не мало.
И тут мы понимаем что чего-то не знаем (Осознанная Некомпетентность).
Начинаем усиленно читать, смотреть конференции. Всеми путями получаем как можно больше знаний.
И когда познаем дзен — переходим в состояние Осознанной Компетенции.
Умеем использовать Репозитории, пилить CQRS и EventSourcing.
Видим правильные проблемы. И умеем их правильно решать.
Это естественный процесс. И очень длительный, если конечно у вас под рукой нет компетентного наставника.
Я не один проект написал с жирными репозиториями, пока научился этому.
Главное задавать как можно больше вопросов и искать ответы. Критически мыслить.
А зависимость от своего интерфейса лучше тем, что:
NIH синдром — это если бы мы пилили действительно всю ОРМ с дата мепперами и юнит оф ворк. А с Репозиторием чаще всего получается как я описал в комменте выше. Т.е. затраты на поддержку === 0. Ведь мы по факту используем то что предоставляет фреймворк, просто внутрь нашего приложения не просочится инородный интерфейс.
Весь паттерн Репозиторий — это про интерфейс, а не про реализацию.
Только не надо добавлять методы с использующие SQL в репозиторий. Это совершенно другая зона ответственности. И назначение другое.
В целом тут на лицо не правильный подход к использованию Репозитория как паттерна. Отсюда и не верное и переусложненное решение.