Частина I. Фундамент та Філософія

https://leanpub.com/architecture-foundation",{"_235":236,"_43":44,"_47":48,"_45":46,"_65":66,"_237":238,"_282":233},"previewContent","

Зміст

Передмова: Чому ця книга існує і як її читати

Вітаю, мої дорогі!

Спочатку про те, хто я такий і чому взагалі маю право розповідати вам про архітектуру. Мене звати Сергій Немчинський. Я в айтішці з 1996 року, відколи закінчив університет. З того часу я встиг попрацювати в купі різних компаній — від дрібних контор до топових українських аутсорсерів та продуктових гігантів, серед яких ЛІГА, Luxoft, Ciklum, Netcracker, IntroPro.

Я пройшов майже всі можливі ролі. Був наймолодшим керівником відділу в ЛІГА:ЗАКОН (до речі, перша пристойна версія їхнього порталу на початку 2000-х писалася саме під моїм керівництвом). Був Project Manager-ом у Ciklum, Архітектором у Luxoft, Тімлідом майже у всіх цих компаніях. Коротше, я бачив процес розробки і з окопів програміста, і з крісла архітектора, і з позиції бізнесу.

Протягом усієї цієї кар’єри я постійно проводив технічні співбесіди та нерідко викладав у корпоративних навчальних центрах. І десь у 2015-2016 роках, коли до мене на співбесіди почали масово приходити випускники різноманітних ІТ-курсів, я з жахом побачив, що вони… майже нічого не знають.

Я запитував їх: “А що ж ви вивчали на ваших курсах?”. Вони з гордістю відповідали: “Ми робили бульбашкове сортування і рахували числа Фібоначчі!”. Я питав: “А Spring вивчали?”. Вони дивилися круглими очима: “Ні, а що таке Spring?”. І це мене просто дико бісило.

Ці курси намагалися за три місяці втиснути п’ятирічну університетську програму, викидаючи все те, що реально потрібно програмісту на роботі: фреймворки, патерни, Enterprise-підходи. Я хапався за голову і врешті-решт вирішив: “Все, повна фігня. Я буду навчати людей сам”. Так у 2016 році з’явилася компанія FoxmindEd, яка успішно навчила вже багато тисяч спеціалістів.

Окрім навчання новачків, ми створюємо серйозні програми для мідлів та сеньйорів. Зокрема, я особисто ще з 2008 року викладаю теорію базової архітектури (GRASP та GoF Design Patterns), а згодом додав до неї і більш просунутий курс з Enterprise-патернів. Спостерігаючи за своїми студентами та за індустрією загалом, я зрозумів, що сучасна освіта для досвідчених розробників має три фундаментальні проблеми. Які мене дико дратують.

Біль №1: Знання у вакуумі

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

Якщо книжка про SOLID, вона жодним словом не згадає про GoF-патерни, ніби їх не існує. Якщо це книжка про GRASP, окрім GRASP там нічого немає. У нещасних студентів виникає суцільний когнітивний дисонанс: вони бачать одну абревіатуру, інтуїтивно відчувають, що вона пов’язана з іншою, але НІХТО не пояснює як саме. Знання літають у голові окремими шматками і ніяк не склеюються до купи.

Біль №2: Застаріле лайно мамонта

Це просто якесь жахіття. Всі курси та книжки по GoF-патернах, які я бачив, просто беруть і слово в слово переказують книгу 1994 року. Йоханий бабай! Минуло більше 30 років!

Вони використовують ті самі діаграми класів, що й у 94-му. Наприклад, патерн Factory Method в тому вигляді, як його малюють у класичних діаграмах, просто не існує в сучасній природі. Так код ніхто не пише. Ба більше, так писати не можна, бо це не вирішує жодної проблеми!

У результаті людина дивиться на UML-діаграму в книжці, дивиться на сучасний код у своєму проєкті, бачить, що вони не співпадають, і вирішує: “Ці ваші патерни — застаріле лайно мамонта”. А це не так! Патерни еволюціонували. Тому в цій книзі я буду “єретиком” — я розповідатиму, як ці патерни використовуються насправді сьогодні.

Біль №3: Сліпа віра у ШІ

Багато хто вважає, що відколи є штучний інтелект, архітектуру можна не вчити: “Він же сам напише код, він такий самовпевнений!”. Ні.

Якщо штучний інтелект згенерує вам код, і на нього подивиться досвідчений архітектор, він одразу зрозуміє: цей код — суцільне лайно. ШІ поки не вміє системно мислити. І напевно ніколи не буде вміти. Єдине, що робить нас кращими за LLM — це наше критичне мислення. А воно неможливе без фундаменту і принципів.

Якщо ви не знаєте китайської, будь-який переклад від ШІ здаватиметься вам правильним. Так само і тут: якщо ви не розумієте архітектури, будь-яка відрижка штучного інтелекту здаватиметься вам нормальним кодом. Ви повинні мати принципи, щоб сказати ШІ: “Ні, так не роби. Роби ось так”. Але щоб це сказати, треба знати як саме.

Для кого ця книга

Ця книга створена для:

\nMiddle та Senior розробників, які відчувають, що їхній код перетворюється на суцільне лайно, і хочуть нарешті побачити “Велику картину”.\n
\nАмбітних Junior-ів, які не хочуть роками писати лайнокод, страждати від цього і не розуміти, куди рухатись далі. Вони хочуть одразу вчити архітектуру.\n
\nВсіх, хто прочитав книгу GoF (до речі, вона дуже нудна, нікому не раджу її читати), нахапався фрагментарних знань, і тепер прагне об’єднати все це в структуровану систему.\n

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

Як ми будемо вчитися: Problem-First

Я інженер, а не науковець. Будь-яке рішення має сенс лише тоді, коли у нас є проблема, яку треба вирішити. Робити “бо це красиво” — це шлях в нікуди. Тому мій підхід — Problem-First. Спочатку ми до болю розбираємо проблему, а лише потім застосовуємо патерн як рішення. І приклади будуть із сучасного життя, а не “сферичні коні” з 90-х.

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

Якось я здав американським замовникам (індійського походження) ідеальний архітектурний документ. Частина діаграм була у форматі Activity (схоже на шкільні блок-схеми). Вони повернули його зі словами: “Будь ласка, намалюйте нам UML, ми взагалі не розуміємо, як виглядає ця діаграма”. Це чудовий показник. Не треба займатися наукоподібним навчанням. Використовуйте прості речі, які зрозумілі всім. Це саме стосується, до речі, і різних тренажерів на кшталт LeetCode — на мій погляд, це сьогодні чистий карго-культ, який не робить ваш код кращим.

Структура: Куди ми йдемо

Ми маємо застекувати всі ваші знання:

\nЗгадаємо базовий фундамент ООП (більшість пам’ятає його зовсім не так, як він є).\n
\nРозберемо правила розподілу відповідальності GRASP (це основа).\n
\nПоєднаємо все це з “технікою безпеки” — принципами SOLID.\n
\nРозглянемо сучасні інструменти мікро-рівня — GoF патерни.\n
\nВизначимо дальні сходинки — куди вам рухатися далі.\n

Подяка Early Access читачам

Окремо хочу подякувати всім, хто купив і читає цю книгу в процесі її написання. Це просто вогонь! Мене це дико надихає.

Я людина відповідальна, але я розумію: якби я вирішив писати одразу всю книгу від початку до кінця, я б її не закінчив ніколи. Будучи директором компанії, я б завжди знаходив інші, “більш важливі” справи. Але якщо мені заплатили гроші — я вже закінчу її точно! Така вже я людина 😄.

Дуже прошу вас: діліться фідбеком. Саме ваші відгуки допомагають мені структурувати, приводити до ладу весь контекст книги і робити її максимально корисною та вивіреною для всіх читачів.

Люблю вас. Залишайтеся з нами, а ми поїхали розбиратися з фундаментом архітектури!

🔑 Висновки розділу

\nАрхітектура потрібна всім: Без неї ви не зможете ні контролювати свій код, ні ставити осмислені задачі штучному інтелекту.\n
\nЗнання мають бути системними: Не можна вчити патерни у відриві один від одного. ООП, GRASP, SOLID та GoF — це єдина взаємопов’язана система.\n
\nProblem-First: Кожен патерн — це інструмент вирішення конкретного болю. Якщо болю немає, патерн не потрібен.\n
\nГеть академізм: Патерни з 1994 року змінилися. Ми вивчатимемо їх так, як вони використовуються в реальному продакшені сьогодні, а не в інститутських методичках.\n

Частина I. Фундамент та Філософія

Цей вміст недоступний у демонстраційній книзі. Книгу можна придбати на Leanpub за адресою https://leanpub.com/architecture-foundation.\n

Розділ 1. Еволюція болю: Від GOTO до ООП

Надворі 2026 рік. У нас є все: ШІ-асистенти, хмарні середовища розробки, фреймворки, які ледь не читають наші думки. Здавалося б, живи і радій, але чому тоді бізнес досі платить шалені гроші Software Architects? Чому на співбесідах сеньйорів досі ганяють по “древніх” патернах?

І чому проєкти, які починаються як “цукерочка”, через рік перетворюються на непідтримуване пекло, яке всі бояться чіпати?

Штучний інтелект генерує код блискавично. Але без розуміння архітектурних патернів ви навіть не зможете оцінити, чи він згенерував чисту архітектуру, чи нечитабельне місиво. Чат-бот видав двісті рядків коду — а ви навіть не знаєте, чи це адекватний дизайн, чи класичний антипатерн.

Відповідь ховається в одному слові: Складність.

Ми століттями боролися з хаосом. І щоб зрозуміти, навіщо вам потрібні правила (такі як GRASP чи SOLID), треба пройти цей шлях еволюції. Повірте, якщо ви не знаєте, як боляче б’ють граблі, на які наступали до вас, ви гарантовано наступите на них сьогодні.

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

Ера Хаосу: Spaghetti Code та GOTO (1960-ті)

Уявіть собі шістдесяті роки. Ми пишемо на Асемблері, Fortran або ранньому BASIC. У нас немає функцій у сучасному розумінні. Немає циклів while чи for. У нас є лише одна суперзброя: оператор GOTO.

Типовий код того часу виглядав приблизно так:

1 Рядок 10: Зроби щось.\n2 Рядок 20: Якщо умова Х — стрибни на рядок 500.\n3 Рядок 500: Зроби щось і стрибни назад на рядок 30.\n

\n\n

Це призводило до явища, яке отримало назву Spaghetti Code. Не в переносному сенсі, а буквально. Якщо ви спробуєте намалювати потік виконання на папері — це буде схоже на тарілку з макаронами. Зрозуміти логіку програми, просто читаючи код зверху вниз, було неможливо. Ви мусили тримати в голові всю карту пам’яті.

Програми ставали непередбачуваними. І ось, у 1968 році, сталася революція. Великий і жахливий Едсгер Дейкстра (Edsger W. Dijkstra) пише свого знаменитого листа в ACM: “Go To Statement Considered Harmful”. Він сказав: “Хлопці, досить стрибати. Нам потрібна структура”.

Ера Структурного програмування та його “Спадщина” (1970-ті)

Так народилося Структурне програмування. Вчені Бом і Якопіні математично довели, що будь-яку програму можна написати, використовуючи всього три конструкції:

\nПослідовність (Sequence): Роби А, потім Б.\n
\nРозгалуження (Selection): if / else.\n
\nІтерація (Iteration): while / for.\n

Усе. Більше ніяких стрибків GOTO. З’явилися процедури і функції. Це був прорив! Код став читабельним від початку до кінця.

Але тут є нюанс, про який мовчать у підручниках. Структурне програмування принесло нам не тільки добро, а й “архітектурні забобони”, які досі псують життя розробникам.

Одне з правил Дейкстри звучало так: “One Entry, One Exit” — один вхід, один вихід.
\nДля мов на кшталт Pascal чи C, де треба було вручну чистити пам’ять перед виходом із функції, це було критично важливо. Ти увійшов, виділив пам’ять, зробив роботу, очистив пам’ять, вийшов. В одній точці.

Але що ми бачимо сьогодні в Java, C# чи PHP? Розробники, сліпо слідуючи цьому правилу, пишуть “Arrow Code” або “Код-стрілу”, з величезною кількістю вкладеностей.

 1 // Антипатерн Arrow Code (Спадщина \"Одного виходу\")\n 2 public String processOrder(Order order) {\n 3     String result = \"Error\";\n 4     if (order != null) {\n 5         if (order.isValid()) {\n 6             if (order.hasPayment()) {\n 7                  // 100 рядків логіки\n 8                  result = \"Success\";\n 9             }\n10         }\n11     }\n12     return result; // Той самий \"єдиний вихід\"\n13 }\n

\n\n\n\n\n

$\"An$

Це антипатерн у сучасному світі!

Сьогодні ми сповідуємо принцип “Fail Fast”. Якщо дані невалідні — робимо return одразу, на самому початку методу. У сучасному дизайні це називається Guard Clauses (загороджувальні конструкції). Це дозволяє тримати код плоским, чистим і зрозумілим.

1 // Сучасний підхід: Guard Clauses (Загороджувальні конструкції)\n2 public String processOrder(Order order) {\n3     if (order == null) return \"Error\";\n4     if (!order.isValid()) return \"Error\";\n5     if (!order.hasPayment()) return \"Error\";\n6     \n7     // 100 рядків логіки на першому рівні вкладеності\n8     return \"Success\";\n9 }\n

\n\n

Не треба тягнути виконання до кінця функції заради святого правила сімдесятих. Правило було для іншого контексту.

Ера Процедурного Пекла: Глобальні дані (1980-ті)

З потоком керування розібралися. Але виникла нова проблема. У процедурному програмуванні дані (змінні) і поведінка (функції) були розділені.

Уявіть собі комунальну квартиру.

\nЗмінні (дані) — це спільний коридор і кухня.\n
\nФункції — це мешканці.\n

Функція А прийшла, взяла змінну User, змінила їй ім’я. Функція Б прийшла, побачила User, видалила його. Функція В намагається нарахувати User зарплату… і програма падає з помилкою Null Reference. Хто винен? Хто змінив дані? Відслідкувати це у великій системі було практично неможливо.

Дані були беззахисні. Будь-яка функція могла їх зіпсувати. Нам потрібен був сейф.

Народження ООП: Клітини і Повідомлення

Тут на сцену виходять скандинави Крістен Нюгорд і Оле-Йохан Дал зі своєю мовою Simula 67 (перша мова з об’єктами), і згодом Алан Кей (Alan Kay), батько мови Smalltalk.

Кей був біологом за освітою. Він подивився на клітину живого організму. Клітина має мембрану. Всередині йдуть складні хімічні процеси: мітохондрії, ядро, ДНК. Але ззовні клітина — це просто капсула. Клітини спілкуються одна з одною через обмін сигналами. Клітина А не лізе “руками” всередину Клітини Б. Вона просто надсилає повідомлення.

Так і народилася Інкапсуляція.
\nМи вирішили: дані — це святе. Ми ховаємо їх всередину об’єкта. Ніхто ззовні не має права їх вільно модифікувати. Хочеш щось зробити? Виклич метод. Надішли об’єкту повідомлення.

\n\n\n\n

$\"An$

Історичний парадокс: Ми перемогли глобальні дані через ООП та інкапсуляцію. Але натомість отримали іншу проблему — Високу пов’язаність (Coupling). Коли C++ захопив світ, люди почали створювати тисячі класів, які залежали один від одного так міцно, що зміна одного файлу ламала половину проєкту.

І ось саме тут, коли класи вже існували, але порядку між ними ще не було, на сцену виходять Архітектори.

Від цегли до байтів: Історія патернів (1977-1994)

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

У 1977 році Крістофер Александер, професор архітектури будівництва, пише книгу “A Pattern Language”. Він усвідомив: проблеми в архітектурі повторюються. Не треба щоразу вигадувати велосипед. Треба описати ці повторювані рішення:

\nContext (Контекст): Де це відбувається?\n
\nProblem (Проблема): Який конфлікт треба вирішити?\n
\nSolution (Рішення): Як це зробити перевіреним способом.\n

Десять років по тому (1987) двоє геніальних програмістів, Кент Бек та Ворд Каннінгем, прочитали Александера і зрозуміли: “У коді ж те саме!”. Вони описали кілька перших патернів програмування. Спочатку індустрія сприйняла це скептично. Але у 1994 році стався великий вибух.

Четверо вчених (Еріх Ґамма, Річард Хелм, Ральф Джонсон, Джон Вліссідес) випускають книгу Design Patterns. Вони увійшли в історію як Банда Чотирьох (Gang of Four, GoF). Вони описали 23 класичні проблеми і дали їм назви: Factory, Command, Observer…

З’явилася спільна мова. Тепер розробник з Києва міг сказати колезі з Каліфорнії: “Застосуй тут Синглтон”, і їм не треба було малювати діаграми пів години.

Темний бік патернів

Здавалося б, щасливий кінець? Ми знайшли Святий Грааль? Ні.

Універсальна мова принесла нові «хвороби»:

\nPatternitis (Патерніт) та “Дитячі травми”: Спочатку це хвороба новачків. Прочитавши книгу GoF, розробник отримує “молоток”, і все навколо починає здаватися йому цвяхом. Він пхає патерни туди, де достатньо одного if/else. Але найгірше починається потім: попекшись на цьому і створивши непідтримуваного монстра, такий розробник доходить висновку, що “патерни — це взагалі маячня”. Дослужившись до позиції Тімліда, він через цю свою “дитячу травму” починає категорично забороняти підлеглим використовувати БУДЬ-ЯКІ патерни. Ця крайність дуже часто зустрічається в нашій індустрії.\n
\nКарго-культ: Люди копіюють структуру патерну, бо “так круто”, але не розуміють проблеми, яку він вирішує.\n

Джуніори ліпили складені Фабрики там, де треба було просто зробити new. Код ставав надскладним.

Протверезіння: GRASP і SOLID

У 1997 році Крейг Ларман випускає книгу “Applying UML and Patterns”. Він подивився на цей хаос і сказав: “Хлопці, ви побігли поперед батька в пекло. Ви вчите складні архітектурні форми (GoF), але ви досі не знаєте базових речей!”

\n\n\n\n

$\"An$

Цікавий факт про книгу Лармана: Це дуже забавна книга сама по собі. Вона напхана абсолютно різнорідними темами, які майже ніяк не пов’язані між собою. У Лармана було багато класних ідей, і він просто “запхав” їх усі в один том, навіть не подбавши про зв’язність. Це часто викликає острах у розробників: людина хоче розібратися в GRASP, купує книгу про UML і патерни, а виявляється, що GRASP — це лише одна з глав, яка стоїть особняком від інших відірваних тем.

Але саме в цій книзі народився GRASP (General Responsibility Assignment Software Patterns). Це не про класи. Це про Відповідальність. У кого є дані, той і робить роботу (Information Expert). Хто об’єкт використовує, той його і створює (Creator). Це фундамент, без якого ваші Синглтони і Декоратори — лише купа сміття.

Пізніше, на початку 2000-х, з’являється Роберт Мартін (відомий як “Uncle Bob”). Треба відразу розвіяти популярний міф: такої книги як “SOLID” у природі не існує.

Насправді, ці п’ять принципів були лише частиною його великої монографії “Agile Software Development, Principles, Patterns, and Practices”. Більше того, сам акронім “SOLID” придумав не він, а Майкл Фезерс (Michael Feathers), який помітив, що якщо скласти перші літери п’яти головних принципів Мартіна, вийде красиве слово. Принципів у тій книзі набагато більше, але ми фокусуємось на базовій п’ятірці.

По суті, SOLID — це ваша техніка безпеки, яка гарантує, що зміна одного класу не підірве інший.

Велика Картина (The Big Picture)

Тепер у вас має скластися повний пазл еволюції інженерної думки:

Бачите логіку? Наша піраміда спускається від загальних архітектурних ідей все ближче і ближче “до землі” — тобто до вашого реального коду та серверів:

\nНа самій вершині абстракції лежить ідеологія ООП. Це концепція капсул і повідомлень.\n
\nСпускаючись на крок нижче, ми маємо GRASP — це приземлені правила розподілу відповідальності (у який клас покласти метод).\n
\nЩе ближче до реальності знаходиться SOLID — “техніка безпеки”, яка гарантує гнучкість зв’язків між вашими класами.\n
\nДалі йде GoF — це інструменти для вирішення локальних, специфічних мікро-задач “на землі” (як створити об’єкт в конкретних умовах). Важливо розуміти: GoF — це не готові рішення для комплексних проблем системи. Це типові “сферичні коні”, дуже локалізовані цеглинки.\n
\nІ вже після них, на самому фундаментальному рівні системної розробки, починається справжня, доросла Макро-архітектура (Enterprise Patterns, мікросервіси, HighLoad) — тобто те, як усі ці “дрібні” абстракції та патерни об’єднуються у величезну працюючу систему.\n

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

А як щодо Функціонального програмування?

Можливо, ви зараз думаєте: “Сергію, зараз хайп навколо функціонального програмування (ФП). Лямбди, стріми, незмінний стан (Immutability). Кажуть, що ООП застаріло. Чому ж ФП просто не вбило ООП і ці ваші патерни?”.

Щоб одразу відбити атаки фанатів чистого ФП (яких у нашій індустрії вистачає), поясню технічні причини. Чисте ФП просто не підходить для реалій більшості сфер розробки (чи то Enterprise, e-commerce, мобільна розробка, фронтенд або геймдев) з трьох фундаментальних причин:

\nПроблема стану (State). Користувацький інтерфейс (UI) — це суцільний мінливий стан. Кнопка натиснута або ні, вікно активне або ні, користувач зробив свайп. У чистій ФП-парадигмі стану немає (Immutability). Намагатися малювати UI або обробляти введення від користувача на чистому ФП — це моделювати мінливий світ за допомогою статичних математичних формул. Це страшенно незручно і виглядає як мазохізм.\n
\nПроблема послідовності (Sequence). Класична бізнес-транзакція (відкрили транзакцію -> перевірили баланс юзера -> списали гроші -> оновили статус -> закрили транзакцію) — це імперативний, послідовний алгоритм команд. ФП за своєю природою мислить категоріями обчислень, а не команд. Тому моделювати послідовні транзакції в чистому ФП — це надзвичайно складна і неприродна задача.\n
\nПобічні ефекти та Монади (Side Effects). Логування, запис у БД, виклики сторонніх API — для чистого ФП це все “побічні ефекти”. Чиста функція має лише прийняти дані і повернути результат без зовнішнього впливу. Щоб якось вирішити це обмеження (і щоб програма могла хоч щось записати в базу), фанати ФП придумали обхідний шлях — “Монади” (на кшталт IO Monad). Але писати реальну бізнес-логіку на Монадах — це гарантовано зламати мозок 90% вашої команди розробників.\n

Тому сучасний світ працює на гібридній архітектурі:

\nМакро-рівень (Бізнес-процеси та UI) — це ООП. Як тільки нам потрібна послідовна логіка, транзакції, збереження стану або малювання інтерфейсу — ми використовуємо ООП і патерни (контролери, сервіси). Побудувати великий Enterprise суто на функціях — це отримати непідтримуване спагеті з аргументів.\n
\nМікро-рівень (Трансформація даних) — це ФП. Усередині методів, коли треба просто відфільтрувати колекцію чи знайти потрібний елемент, ми використовуємо map, filter, чисті функції. Тут ФП безумовно перемагає.\n

Більше того, ФП часто спрощує класичні патерни. Наприклад, патерн “Стратегія” в ООП вимагав інтерфейсу і низки класів. З появою лямбд він перетворився на просту передачу функції як параметра. Суть залишилася (ізолювати алгоритм від клієнта) — синтаксис спростився.

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

Готові? Рухаємося до Архітектурних драйверів.

🔑 Висновки розділу

Що варто запам’ятати з цієї історії болю:

\nЕволюція — це вирішення попередньої проблеми. Структурне програмування вбило Spaghetti Code, а ООП перемогло “комуналку” глобальних станів. Не знаючи цього болю, ви не зрозумієте логіку патернів.\n
\nСліпе слідування правилам минулого — антипатерн. Старе правило “одна точка виходу з функції” зараз породжує нечитабельний Arrow Code. Замінюйте його на сучасний Fail Fast (Guard Clauses).\n
\nПатерн — це інструмент, а не самоціль. Якщо ви застосовуєте GoF-патерн (“Стратегію”, “Фабрику”) там, де було б достатньо звичайного if/else — ви захворіли на “Патерніт” та займаєтесь овер-інжинірингом.\n
\nВід абстракції до землі. Архітектурне мислення будується згори донизу: спочатку розуміння ідеології ООП, потім правила розподілу відповідальності (GRASP), далі техніка безпеки зв’язків (SOLID), потім мікро-рішення (GoF), і лише на найнижчому (найширшому) рівні — Макро-архітектура (Enterprise, мікросервіси та HighLoad).\n
\nЖодної війни парадигм. Ми живемо в епоху гібридної архітектури. ООП ідеально працює на макро-рівні (структура модулів і класів), а Функціональне програмування рятує нас від проблем стану (Mutable State) на мікро-рівні всередині функцій.\n

Розділ 2. За що вам платять гроші? Архітектурні драйвери та мистецтво Trade-offs

ЩО проти ЯК: Функціональні та Нефункціональні вимоги

Функціональні вимоги (FR) — “ЩО”

Нефункціональні вимоги (NFR) — “ЯК”

Сучасна шістка драйверів

1. Maintainability (Підтримуваність)

2. Scalability (Масштабованість)

3. Reliability (Надійність)

4. Security (Безпека)

5. Testability (Тестованість)

6. Observability (Спостережуваність)

Мистецтво компромісу (Trade-offs)

Performance vs Maintainability (Продуктивність проти Підтримуваності)

Flexibility vs Time-to-Market (Гнучкість проти Швидкості запуску)

Теорема CAP

Жорсткі обмеження (Constraints)

🔑 Висновки розділу

Розділ 3. Парадокс ООП: Ви думаєте, що знаєте, — але ні

Що таке парадигма?

Швидкий огляд «сусідів» ООП

Функціональне програмування (ФП)

Аспектно-орієнтоване програмування (АОП)

Реактивне програмування

Алан Кей та Біологічна метафора

Messaging: Прохання замість Наказу

Стан + Поведінка = Нероздільна Єдність

Антипатерн: Анемічна Модель (Anemic Domain Model)

Велика картина: де ми?

🔑 Висновки розділу

Розділ 4. Інкапсуляція: Два обличчя “чорної скриньки”

Велика ілюзія безпеки

Дві трактовки: Від Сімули до Вікіпедії

Інкапсуляція як архітектурний принцип

Навіщо це треба: Гайка, Жопа та Race Conditions

Рішення: Справжній ООП-об’єкт

🔑 Висновки розділу

Частина II. GRASP: Мистецтво розподілу відповідальності

Частина III. SOLID: Принципи гнучкості

Частина IV. Патерни GoF (Банда Чотирьох) у сучасному світі

Цей вміст недоступний у демонстраційній книзі. Книгу можна придбати на Leanpub за адресою https://leanpub.com/architecture-foundation.\n\n

\n\n","tocStructure",[239,240,241,242,243,244,245,246,247,248,249,250,251,252,253,254,255,256,257,258,259,260,261,262,263,264,265,266,267,268,269,270,271,272,273,274,275,276,277,278,279,280,281],{"_75":76,"_43":77,"_70":-5,"_78":79,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":85,"_70":-5,"_78":86,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":91,"_70":-5,"_78":92,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":94,"_70":-5,"_78":95,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":97,"_70":-5,"_78":98,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":100,"_70":-5,"_78":101,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":103,"_70":-5,"_78":104,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":106,"_70":-5,"_78":107,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":109,"_70":-5,"_78":110,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":112,"_70":-5,"_78":113,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":116,"_70":-5,"_78":117,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":120,"_70":-5,"_78":121,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":123,"_70":-5,"_78":124,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":126,"_70":-5,"_78":127,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":129,"_70":-5,"_78":130,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":132,"_70":-5,"_78":133,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":135,"_70":-5,"_78":136,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":138,"_70":-5,"_78":139,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":141,"_70":-5,"_78":142,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":109,"_70":-5,"_78":144,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":146,"_70":-5,"_78":147,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":150,"_70":-5,"_78":151,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":153,"_70":-5,"_78":154,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":156,"_70":-5,"_78":157,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":109,"_70":-5,"_78":159,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":161,"_70":-5,"_78":162,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":165,"_70":-5,"_78":166,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":168,"_70":-5,"_78":169,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":171,"_70":-5,"_78":172,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":174,"_70":-5,"_78":175,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":177,"_70":-5,"_78":178,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":180,"_70":-5,"_78":181,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":109,"_70":-5,"_78":183,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":185,"_70":-5,"_78":186,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":189,"_70":-5,"_78":190,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":192,"_70":-5,"_78":193,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":195,"_70":-5,"_78":196,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":198,"_70":-5,"_78":199,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":201,"_70":-5,"_78":202,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":84,"_43":109,"_70":-5,"_78":204,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":206,"_70":-5,"_78":207,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":210,"_70":-5,"_78":211,"_71":80,"_87":-5,"_88":-5,"_89":-5},{"_75":76,"_43":214,"_70":-5,"_78":215,"_71":80,"_87":-5,"_88":-5,"_89":-5},"publicChapterContent","nextChapter","sections",[],"routes/_store+/_layout","routes/_store+/_readers+/_layout","actionData","errors"]