Чи "Чиста архітектура" Боба Мартіна є основним правилом для всіх архітектур чи це лише один із варіантів?


22

Мені дуже сподобалися концепції у відео «Принципи чистої архітектури» дядька Боб Мартіна . Але я відчуваю, що цей зразок схожий на поєднання абстрактних моделей Factory and Builder в основі.

Це один із способів написання хороших програм, але не єдиний спосіб.

Rails and reactjs - це 2 рамки, які приходять в голову, що не сприяють такому чистому архітектуру. Rails очікує, що ваша бізнес-логіка буде в моделях ( FatModels і SkinnyControllers ) і реагуватиме всередині ваших компонентів. Обидва підходи щільно поєднують логіку бізнесу та рамковий код .

Я не знаходжу нічого поганого в жодному з трьох способів. Це заклик вибору вибрати будь-який.

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

Отже, чи "Чиста архітектура" Боба Мартіна є основним правилом для всіх архітектур чи це лише один із варіантів?


16
«Чиста архітектура» - це те, що винайшов Боб Мартін. Це воно.
Роберт Харві

2
Можливо, краще питання таке:. Rails і React дико успішні. Що написав Боб Мартін, використовуючи чисту архітектуру, для порівняння? Я хотів би дізнатися відповідь сам.
user949300

4
Прочитайте публікацію в блозі Джоела про п’ять світів , і ви знаєте, чому не існує "правила" для всіх архітектур ".
Док Браун

1
Рейки можуть бути дуже успішними для запуску та складання прототипів. Коли приходить час підтримувати та розвиватись ще з 50 іншими розробниками - "свобода" Rails стає проблемою, з якою борються старші розробники.
Фабіо

Представлено вашій увазі: Baruco 2012: Deconstructing the Framework, автор Gary Bernhardt
Theraot

Відповіді:


34

Хоча «Чиста архітектура» є прекрасною та має багато переваг, важливо пам’ятати, що:

  • Чиста архітектура значною мірою є ребрендингом Роберта К. Мартіна та еволюцією суміжних підходів, таких як Лукова архітектура Джефрі Палермо (2008) та Гексагональна архітектура («Порти та адаптери») Алістера Кокберна та інших (<2008).

  • До різних проблем пред’являються різні вимоги. Чиста архітектура та пов'язані з цим підходи перетворюють роз'єднання, гнучкість та інверсію залежності до одинадцяти, але жертвують простотою. Це не завжди гарна угода.

Попередник цих архітектур - класичний шаблон MVC від Smalltalk. Це роз'єднує модель від інтерфейсу користувача (контролер та подання), щоб модель не залежала від інтерфейсу користувача. Існує багато варіантів MVC, таких як MVP, MVVM,….

Більш складні системи не мають лише одного користувальницького інтерфейсу, але, можливо, декілька інтерфейсів користувача. Багато додатків вирішують запропонувати API REST, який може споживатися будь-яким інтерфейсом, наприклад веб-додатком або мобільним додатком. Це ізолює ділову логіку на сервері від цих інтерфейсів, тому сервер не хвилює, який саме додаток має доступ до нього.

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

Шестикутна архітектура йде далі і зупиняє робити розрізнення між кордоном і резервним. Будь-яка зовнішня система може бути входом (джерелом даних) або виходом. Наша основна система визначає необхідні інтерфейси (порти), і ми створюємо адаптери для будь-яких зовнішніх систем.

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

Усі ці підходи мають такі переваги , як полегшення тестування системи в ізоляції (заміни всіх зовнішніх систем, з якими вона взаємодіє, на макетних реалізаціях). Вони полегшують надання декількох реалізацій для одного виду послуги (наприклад, додавання другого процесора платежів) або замінюють реалізацію послуги (наприклад, перехід із бази даних Oracle на PostgreSQL або перезапис сервісу Python у Go) .

Але ці архітектури є Ferrari архітектур: дорогі, і більшість людей їм не потрібні. Додаткова гнучкість чистої архітектури тощо пояснюється більшою складністю. Багато прикладних програм, а особливо CRUD-сайтів, від цього не виграють. Має сенс виділити речі, які можуть змінитися, наприклад, за допомогою шаблонів для створення HTML. Менше сенсу ізолювати речі, які навряд чи зміняться, наприклад, резервна база даних. Що, можливо, зміниться, залежить від контексту та потреб бізнесу.

Каркаси роблять припущення щодо того, що буде змінюватися. Eg React схильний вважати, що дизайн та поведінка компонента змінюються разом, тому розділяти їх не має сенсу. Небагато фреймворків припускають, що ви можете змінити рамку. Таким чином, рамки представляють кількість блокування. Наприклад, залежність Рейла від (дуже впевненої!) Схеми активного запису ускладнює неможливість змінити стратегію доступу до даних на (часто вищу) схему сховища. Якщо ваші очікування змін не відповідають рамкам, використання іншого фрейма може бути кращим. Багато інших веб-рамок не передбачають жодних припущень щодо доступу до даних.


20
Побічна примітка: Роберт С Мартин має таку нещасну тенденцію представляти щось як найкращу річ і припускає, що це єдиний розумний підхід. Зазвичай він не зовсім помиляється. Але він часто упускає обговорення потенційних недоліків і схильний до гіперболи. В результаті його поради мають тенденцію вводити в оману. Тому краще повністю ігнорувати все, що він каже.
амон

2
Я люблю слухати таке твердження, тому що так часто я зустрічаю людей, які сліпо намагаються слідувати кожній дрібниці, яку він каже. Принаймні, якби застосувати підхід "це один спосіб, який часто працює, але завжди пильно пильнуй", я можу почуватись краще за нього, але я не можу реально сказати, що я фанат Роберта Мартіна
jleach

6
Це смішно, бо я пригадую його, підкреслюючи, що його рішення було не єдиним у книзі. Потім він розповів про своє рішення в більшій глибині. Особисто я не переймаюся деякими його повідомленнями, але Clean Architecture був чудовим читачем.
bitsoflogic

2
@bitsoflogic Це добре знати! TBH Я не читав його книг, і моя думка ґрунтується на його розмовах, статтях та на питаннях людей, які читають його матеріали. Поки що я бачив більше прикладів, коли йому не вистачає будь-якого помітного нюансу. Це справжня проблема, враховуючи, що Clean Code продається багато молодшим розробникам, які ще не можуть поставити його думки в контекст. Його розмова про чисту архітектуру (це питання засноване на записі), схоже, не обговорює обмежень. Для цільової аудиторії це добре, для кожного, хто вважає його «авторитетом», він представляє оману з точки зору.
амон

1
@amon Мені б дуже хотілося, щоб хтось більш детально розповідав про час і місце для багатьох моделей та архітектур. Зазвичай вони зобов'язані вирішувати певну проблему, будь то через мову кодування чи ділову потребу, проте дискусії завжди зосереджуються на тому, як реалізувати. Що стосується книги, то його знання історії кодування (проживши її) вдалося поставити унікальний погляд на речі. Однак, я думаю, що ви в основному знайдете той самий випуск у книзі, який ви бачили на переговорах.
bitsoflogic

24

Мені дуже сподобалися концепції у відео «Принципи чистої архітектури» дядька Боб Мартіна. Але я відчуваю, що цей шаблон є як поєднання моделей абстрактних заводів та будівельників в основі.

Навіть близько не.

Коли ви дивитесь на це:

введіть тут опис зображення

Ви дивитесь на дизайн об’єктного графіка. Це диктує те, що відомо про що. Чого не вистачає в цій історії, як побудований цей графік об'єктів. Вибачте, але ви тут цього не знайдете. Немає жодної згадки про будівництво.

Ви можете побудувати все це без абстрактних фабрик і будівельників. Я знаю, тому що я це зробив . Я навіть не збирався їх уникати. Я люблю їх. Мені просто не трапилось їх потребувати. Я просто використав передачу посилання. Ін'єкція залежності - це вигадний термін для цього.

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

Тепер речі повинні існувати, перш ніж ви зможете засунути їх в інші речі. Я дослідив це тут і дав йому цю милу маленьку діаграму:

введіть тут опис зображення

І ви можете все це побудувати, навіть не відходячи main().

Я б рекомендував використовувати будівельників і фабрик, коли ви хочете розбити купу процесуального будівельного коду на приємні концептуальні шматки. Але в чистій архітектурі чи будь-якій іншій архітектурі модного слова немає нічого, що вимагає від вас. Тож якщо ви хочете дотримуватися main(), добре. Просто будь ласка, помилуй .

Чи "Чиста архітектура" Боба Мартіна є основним правилом для всіх архітектур чи це лише один із варіантів?

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

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

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

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

Але на відео, який я відчуваю, він пропонує, що чиста архітектура повинна мати чітку межу між логікою бізнесу та рамками. Рамки (веб, андроїд тощо) повинні бути плагінами, які підключаються до бізнес-логіки. Він навіть тонко знущається з рейок у відео.

Ти правий. Він робить. Дядько Боб вважає, що до каркасів можна ставитися як до бібліотек. І вони можуть. Але навіть це рішення чогось коштує тобі.

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

Поки ваші потреби передбачаються рамками, все буде йти дуже гладко. Приємно передбачити ваші потреби. Він поміщає вас у вікно, яке забезпечує прості речі. Просто зрозумійте, що ви віддаєте, щоб це отримати. Якщо ви поширюєте Весну скрізь, ви більше не можете її рекламувати як роботу на Java. Це робота Java / Spring. Я міг би сказати те ж саме про Рубі і Рейлс, але Райлс давно їв обід Рубі.


4

Для цитування відео:

"Ви не хочете робити злиття пошти в SQL."

далі:

"Я насправді бачив процедуру, що зберігається в SQL, яка була цілим злиттям пошти"

Архітектура, як і злиття пошти, є лише одним із варіантів серед багатьох.

Не обов’язково - це проблеми, які архітектура намагається вирішити.

Якщо ви розумієте, які проблеми злиття пошти SQL викликає порівняно з іншими рішеннями, тоді ваш вибір архітектури буде проінформований, і навіть якщо ви змушені будете вибирати "погані" рішення, ви будете обізнані і зменшувати свої недоліки.

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


2

"Чиста архітектура", безумовно, "лише" один із варіантів. Я зауважу, що це один із поганих варіантів для більшості проектів, особливо для об'єктно-орієнтованих проектів.

Ось аналіз статей за реченням статті дядька Боба про чисту архітектуру з причинами вищезазначеного твердження:

Чиста архітектура з об'єктно-орієнтованої точки зору


1

Чиста архітектура - це набір принципів та зразків, спрямованих на вирішення ряду поширених симптомів, з якими організації, що розробляють програмне забезпечення, часто стикаються впродовж життя складної програми. Г-н Мартін у великій мірі розглядає книгу, щоб визначити симптоми та основні причини, що ґрунтуються на його великому досвіді в цій галузі, та уточнити роль архітектури у пом'якшенні цих проблем.

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


це , здається, не пропонує нічого істотного по точкам , зроблених і пояснено в 4 попередніх відповідях
комар
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.