Мне очень понравились концепции в видео «Принципы чистой архитектуры» дяди Боба Мартина . Но я чувствую, что этот шаблон похож на комбинацию шаблонов Abstract Factory и Builder по своей сути.
Это один из способов написания хороших программ, но не единственный.
Rails и responsejs - две структуры, которые приходят на ум, которые не продвигают этот вид чистой архитектуры. Rails ожидает, что ваша бизнес-логика будет в моделях ( FatModels и SkinnyControllers ) и будет реагировать внутри ваших компонентов. Оба подхода тесно связаны между собой бизнес-логикой и структурным кодом .
Я не нахожу ничего плохого ни в одном из 3 способов. Это суждение, чтобы выбрать любого.
Но в видео я чувствую, что он предполагает, что чистая архитектура должна иметь четкую границу между бизнес-логикой и фреймворками. Каркасы (веб, андроид и т.д.) должны быть модули , которые подключаются , чтобы к бизнес - логике. Он даже тонко издевается над рельсами на видео.
Итак, «Чистая архитектура» Боба Мартина является практическим правилом для всех архитектур или это только один из вариантов?
источник
Ответы:
Хотя «Чистая архитектура» хороша и имеет много преимуществ, важно помнить, что:
«Чистая архитектура» - это в основном ребрендинг Роберта Мартина и развитие связанных с ним подходов, таких как «Луковая архитектура» Джеффри Палермо (2008) и «Шестиугольная архитектура» («Порты и адаптеры») Алистера Кокберна и других (<2008).
Разные проблемы имеют разные требования. Чистая архитектура и связанные с ней подходы превращают развязку, гибкость и инверсию зависимостей в одиннадцать, но жертвуют простотой. Это не всегда хорошая сделка.
Предшественником этих архитектур является классический шаблон MVC от Smalltalk. Это позволяет отделить модель от пользовательского интерфейса (контроллера и представления), чтобы модель не зависела от пользовательского интерфейса. Существует много вариаций MVC, таких как MVP, MVVM,….
Более сложные системы имеют не только один пользовательский интерфейс, но, возможно, несколько пользовательских интерфейсов. Многие приложения предпочитают предлагать API REST, который может использоваться любым пользовательским интерфейсом, например веб-приложением или мобильным приложением. Это изолирует бизнес-логику на сервере от этих пользовательских интерфейсов, поэтому сервер не заботится о том, какое приложение обращается к нему.
Как правило, сервер по-прежнему зависит от внутренних служб, таких как базы данных или сторонние поставщики. Это прекрасно, и приводит к простой многоуровневой архитектуре.
Гексагональная архитектура идет дальше и перестает делать различие между внешним и внутренним интерфейсом. Любая внешняя система может быть входом (источником данных) или выходом. Наша базовая система определяет необходимые интерфейсы (порты), и мы создаем адаптеры для любых внешних систем.
Одним из классических подходов к сильной развязке является сервис-ориентированная архитектура (SOA), где все сервисы публикуют события и используют события из общей шины сообщений. Подобный подход впоследствии был популяризирован микросервисами.
Все эти подходы имеют свои преимущества , такие как упрощение тестирования системы в отдельности (путем замены всех внешних систем, с которыми она взаимодействует, на фиктивные реализации). Они упрощают предоставление нескольких реализаций для одного вида сервиса (например, добавление второго процессора платежей) или замену реализации сервиса (например, переход от базы данных Oracle к PostgreSQL или переписывание службы Python в Go). ,
Но эти архитектуры - Ferrari архитектур: дорогие, и большинству людей они не нужны. Дополнительная гибкость чистой архитектуры и т. Д. Достигается за счет большей сложности. Многие приложения и особенно веб-приложения CRUD не получают от этого пользы. Имеет смысл изолировать вещи, которые могут измениться, например, с помощью шаблонов для генерации HTML. Не имеет смысла выделять вещи, которые вряд ли могут измениться, например, резервную базу данных. Что может измениться, зависит от контекста и потребностей бизнеса.
Рамки делают предположения о том, что будет меняться. Например, React предполагает, что дизайн и поведение компонента меняются вместе, поэтому разделять их не имеет смысла. Немногие фреймворки предполагают, что вы можете захотеть изменить фреймворк. Как таковые, фреймворки действительно предоставляют определенную блокировку. Например, зависимость Rail от (очень самоуверенного!) Шаблона Active Record делает невозможным или невозможным изменение вашей стратегии доступа к данным (часто превосходящей) модели репозитория. Если ваши ожидания изменений не соответствуют структуре, лучше использовать другую структуру. Многие другие веб-фреймворки не делают никаких предположений о доступе к данным.
источник
Даже не близко.
Когда вы смотрите на это:
Вы смотрите на дизайн графа объекта. Это диктует, что знает о чем. Чего не хватает в этой истории, так это того, как был построен этот объектный граф. Извините, но вы не найдете этого здесь. Там нет никаких упоминаний о строительстве.
Вы можете построить все это без абстрактных фабрик и застройщиков. Я знаю, потому что я сделал это . Я даже не собирался избегать их. Я их люблю. Просто мне они не нужны. Я просто использовал передачу ссылок. Инъекция зависимости - это причудливый термин для этого.
На самом деле, я мог бы построить все, что вы видите на этой диаграмме в основном. Затем просто вызовите один метод для одного объекта, чтобы все началось.
Теперь вещи должны существовать, прежде чем вы сможете столкнуть их в другие вещи. Я исследовал это здесь и дал ему эту симпатичную небольшую диаграмму:
И вы можете построить все это, даже не уходя
main().Я бы порекомендовал использовать сборщики и фабрики, когда вы хотите разбить кучу процедурного кода конструкции на красивые кусочки концептуального размера. Но в чистой архитектуре или любой другой архитектуре модных слов нет ничего, что требовало бы этого. Так что, если вы хотите придерживаться
main(), хорошо. Просто, пожалуйста, помилуй .Я считаю Чистую Архитектуру модным словом, используемым для привлечения людей к блогу и книге. Этот блог и книга содержат очень хорошие объяснения очень похожих старых архитектур с более старыми именами, которые используются для привлечения людей к старым блогам и старым книгам. В частности, лук, а также порты и адаптеры. Ни один из которых не является единственными архитектурными вариантами, которые у вас есть.
Мне нравится дядя Боб, потому что он потрясающий оратор и автор. Он заставляет меня думать о вещах, которых у меня не было бы иначе. Но если вы позволите этому превратить вас в религиозного фанатика, который настаивает на том, что все должно быть сделано по-своему, вы быстро обнаружите, что обновление документации - самое близкое, что я позволю вам добраться до моего кода.
Архитектуры модных слов полезны, когда у вас есть долгоживущий код, который должен сохраняться, пока мир вокруг него меняется. Вот когда это светит. Если мир стабилен по сравнению с кодом, то вы делаете вещи причудливыми без веской причины.
Неважно, насколько удивительным кажется что-то, есть контекст, в который вы можете поместить это, что сделает это абсурдом. Извините, это тоже не серебряная пуля.
Вы правы. Он делает. Дядя Боб считает, что фреймворки можно рассматривать как библиотеки. И они могут. Но даже это решение стоит вам чего-то.
Мистер Мартин пытается сохранить пространство, в котором ваш общий язык все еще остается общим. Вы отказываетесь от этого, когда распространяете рамки повсюду. Когда вы делаете это, вы идете по пути превращения вашего языка в нечто, называемое языком, специфичным для предметной области. HTML - это предметно-ориентированный язык. Он делает свою работу очень хорошо, но есть другие работы, которые он не может делать вообще.
Пока ваши потребности предвидятся рамками, все будет идти очень гладко. Приятно предвидеть ваши потребности. Он помещает вас в коробку, в которой все просто. Просто пойми, что ты сдаешь, чтобы получить это. Если вы будете распространять Spring повсюду, вы больше не сможете рекламировать его как работу на Java. Это работа на Java / Spring. Я мог бы сказать то же самое о Ruby и Rails, но Rails съел обед Ruby давным-давно.
источник
Цитировать видео:
с последующим:
Архитектура, как слияние почты, является лишь одним из многих вариантов.
Что не является обязательным, так это проблемы, которые архитектура пытается решить.
Если вы понимаете, какие проблемы вызывает слияние почты SQL с другими решениями, тогда ваш архитектурный выбор будет проинформирован, и даже если вы будете вынуждены выбирать «плохие» решения, вы будете знать о них и уменьшать их недостатки.
Если вы следуете архитектурному стилю только потому, что он хорошо продуман, то вы, скорее всего, допустите ошибки и столкнетесь с такими же проблемами.
источник
«Чистая архитектура», безусловно, «только» один из вариантов. Я бы сказал, что это один из плохих вариантов для большинства проектов, особенно для объектно-ориентированных проектов.
Вот анализ за предложением статьи дядюшки Боба о чистой архитектуре с предложениями за предложениями:
Чистая архитектура с объектно-ориентированной точки зрения
источник
Чистая архитектура - это набор принципов и шаблонов для решения ряда общих проблем, с которыми организации по разработке программного обеспечения часто сталкиваются в течение всей жизни при создании сложных приложений. Г-н Мартин очень подробно рассказывает в книге, чтобы определить симптомы и коренные причины, основываясь на своем обширном опыте в данной области, и прояснить роль архитектуры в смягчении этих проблем.
Тем не менее, это не правило большого пальца, ни панацея от всех болезней. Если вы прочитаете книгу, вы лучше поймете, если / когда / как применять принципы и модели, которые он защищает (и соответствующие компромиссы). Если вы не читали книгу, вы, вероятно, сделаете неверные предположения, заявления, суждения и заявления, основанные на неполной информации.
источник