Kick off your book project in 3 hours! Live workshop on Zoom. You’ll leave with a real book project, progress on your first chapter, and a clear plan to keep going. Saturday, June 6, 2026. Learn more…

Leanpub Header

Skip to main content

Фундамент архітектури

База, якої вас ніколи не вчили

Bu kitap % 68 tamamlandıBu kitabın son güncelleme zamanı 2026-05-14.

Чому проєкт-цукерочка через рік перетворюється на непідтримуване пекло? Тому що вас ніколи не вчили базі. Ця книга — єдина система координат, яка нарешті збере ваші розрізнені знання про ООП, GRASP, SOLID та GoF в одну цілісну картину.

En düşük fiyat

$24.98

$34.99

Ödeyeceğiniz Miktar

Yazarın kazandığı

$

Ekibiniz için birden fazla kopya mı alıyorsunuz? İndirim için aşağıya bakın!

PDF
EPUB
WEB
318
Sayfa
55,437Kelimeler
Hakkında

Hakkında

Kitap Hakkında

Ви знаєте синтаксис своєї мови. Ви використовували кілька фреймворків. Ви, можливо, навіть читали про паттерни GoF або SOLID. Але коли доходить до реального проєкту, виникає питання: "А як це все об'єднати разом?"

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

Ця книга — саме та база.

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

Що всередині?
  • Problem-first підхід: Ми не малюємо UML-діаграми ідеального світу. Ми беремо "код джунів", дивимося, як він розвалюється під вагою вимог замовника, і лише тоді застосовуємо патерн.
  • Мультипарадигменність: Книга не прив'язана до однієї мови. Приклади адаптовані так, щоб їх зрозумів розробник на JS, Python, PHP, Java чи C#.
  • Візуалізація: Десятки Mermaid-діаграм, які показують "до" і "після".
  • Дорожня карта розвитку: Ви отримаєте вектор. Ви зрозумієте, де ви знаходитесь зараз і які теми (мікросервіси, Event-Driven, DDD) вивчати далі, спираючись на цей фундамент.
Для кого ця книга?
  • Для мідлів та сеньорів, які хочуть систематизувати свої знання та перестати "винаходити велосипеди".
  • Для джуніорів, які хочуть одразу почати писати код, за який не буде соромно через півроку.

Просто почніть читати. І ви скажете: "Нарешті все стало на свої місця".

Книга пишеться у відкритому режимі. Ви купуєте зараз — і отримуєте всі майбутні оновлення безкоштовно. Ваш фідбек буде враховано прямо в процесі написання.

Bu kitabı Paylaş

Tamamlanan yüklemeler

2 / 4

Takım İndirimleri

Takım İndirimleri

Bu kitap için takım indirimi alın!

  • 3 üyeye kadar

    En düşük fiyat
    $62.00
    Önerilen Fiyat
    $87.00
  • 5 üyeye kadar

    En düşük fiyat
    $99.00
    Önerilen Fiyat
    $139
  • 10 üyeye kadar

    En düşük fiyat
    $174
    Önerilen Fiyat
    $244
  • 15 üyeye kadar

    En düşük fiyat
    $249
    Önerilen Fiyat
    $349
  • 25 üyeye kadar

    En düşük fiyat
    $374
    Önerilen Fiyat
    $524

Yazar

Yazar Hakkında

Сергій Немчинський

Сергій Немчинський — досвідчений IT-інженер, архітектор систем та ментор, який пише код та створює архітектуру з 1996 року.

Він побачив індустрію з усіх можливих ракурсів: з окопів програміста, з крісла архітектора та з позиції бізнесу, працюючи у провідних продуктових та аутсорсингових гігантах (ЛІГА:ЗАКОН, Luxoft, Ciklum, Netcracker).

У 2016 році, втомившись від низької якості "швидких курсів", які готують розробників без базового розуміння інженерії, Сергій заснував компанію FoxmindEd. З 2008 року він активно викладає архітектуру, роблячи акцент на підході "Problem-First": кожен архітектурний патерн чи підхід має сенс лише тоді, коли вирішує конкретну проблему проєкту, а не використовується "бо це модно".

Наразі Сергій не лише керує власною компанією, а й розвиває один із найбільших IT-каналів на українському YouTube. Книга "Фундамент Архітектури" — це квінтесенція його багаторічного досвіду менторства та бойової розробки, написана для тих, хто хоче бачити "велику картину" за межами щоденного кодінгу.

İçerik

İçindekiler

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

  1. Біль №1: Знання у вакуумі
  2. Біль №2: Застаріле лайно мамонта
  3. Біль №3: Сліпа віра у ШІ
  4. Для кого ця книга
  5. Як ми будемо вчитися: Problem-First
  6. Структура: Куди ми йдемо
  7. Подяка Early Access читачам
  8. 🔑 Висновки розділу

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

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

  1. Ера Хаосу: Spaghetti Code та GOTO (1960-ті)
  2. Ера Структурного програмування та його “Спадщина” (1970-ті)
  3. Ера Процедурного Пекла: Глобальні дані (1980-ті)
  4. Народження ООП: Клітини і Повідомлення
  5. Від цегли до байтів: Історія патернів (1977-1994)
  6. Протверезіння: GRASP і SOLID
  7. Велика Картина (The Big Picture)
  8. А як щодо Функціонального програмування?
  9. Сучасність: Як виглядають патерни зараз?
  10. 🔑 Висновки розділу

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

  1. ЩО проти ЯК: Функціональні та Нефункціональні вимоги
  2. Сучасна шістка драйверів
  3. Три вершники складності
  4. Мистецтво компромісу (Trade-offs)
  5. 🔑 Висновки розділу

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

  1. Що таке парадигма?
  2. Швидкий огляд «сусідів» ООП
  3. Алан Кей та Біологічна метафора
  4. Messaging: Прохання замість Наказу
  5. Стан + Поведінка = Нероздільна Єдність
  6. Велика картина: де ми?
  7. 🔑 Висновки розділу

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

  1. Велика ілюзія безпеки
  2. Дві трактовки: Від Сімули до Вікіпедії
  3. Інкапсуляція як архітектурний принцип
  4. Навіщо це треба: Гайка, Жопа та Race Conditions
  5. Рішення: Справжній ООП-об’єкт
  6. 🔑 Висновки розділу

Розділ 5. Наслідування: коли світ б’є вас по потилиці

  1. Чому наслідування взагалі існує?
  2. Золоте правило: IS-A
  3. Реальний кейс: Медогляд і Квіти
  4. Множинне наслідування та Diamond Problem
  5. Правила виживання: скільки рівнів — норма?
  6. 🔑 Висновки розділу

Розділ 6. Поліморфізм: вбивця if-else та справжнє серце ООП

  1. Два типи поліморфізму: справжній і «цукровий»
  2. Еволюція болю: від «Бібліотеки» до «Дерева смерті»
  3. Рішення: Плагінна архітектура
  4. Duck Typing: поліморфізм без ієрархії
  5. Антипатерн: об’єкт без поведінки вбиває поліморфізм
  6. 🔑 Висновки розділу

Розділ 7. Абстракція: мистецтво ігнорувати деталі

  1. Що таке аналіз насправді?
  2. Абстракція є у всіх парадигмах
  3. Три принципи — один результат
  4. Антипатерн: занадто абстрактно
  5. Реальна історія: коли дизайн занадто точний
  6. Золоте правило: інтерфейс — завжди, балаган — ніколи
  7. 🔑 Висновки розділу та підсумок ООП-модуля

Розділ 8. UML: Навіщо малювати, якщо можна кодити?

  1. Як ми домовилися про мову
  2. Міф про «Магічну кнопку» та Rational Rose
  3. «Як роблять джуни» або Кнопка Зла
  4. Суть підходу: UML як «Детектор Гівнокоду»
  5. Тонкощі та Trade-offs: Інструменти і Пастка коду
  6. Чому ми беремо тільки дві діаграми з усіх можливих
  7. 🔑 Висновки розділу

Розділ 9. Анатомія класу та битва стрілок: Class Diagram

  1. Анатомія “Квадратика”
  2. Залежності: Хто кого смикає
  3. Битва Ромбиків: Агрегація vs Композиція
  4. Мультиплікатори: Скільки вішати в грамах?
  5. Генералізація і Чупа-чупси
  6. Нотатки (стикери) та Dependency Injection
  7. 🔑 Висновки розділу

Розділ 10. Життя об’єктів у рантаймі: Sequence Diagram

  1. Коли статика бреше
  2. Анатомія Sequence Diagram
  3. «Як роблять джуни»: Антипатерни зайвої деталізації
  4. Рішення: Хірургічний інструмент, а не малярний валик
  5. Гранд-фінал: Навіщо взагалі вчити UML у 2026 році?
  6. 🔑 Висновки розділу

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

Розділ 11. Вступ до GRASP та патерн Information Expert

  1. Що таке GRASP загалом?
  2. Анатомія об’єкта: Стан та Поведінка
  3. Шлях Експерта на прикладі чека
  4. Коли Експерт стає Монстром: Анемічна модель і кейс DirecTV
  5. Модерн-процедуралізм та Smart Data
  6. 🔑 Висновки розділу

Розділ 12. Creator (Творець): Хто дає життя об’єктам?

  1. Процедурна помилка початківців
  2. Правила Лармана: Хто має “ліцензію” на new?
  3. Велика битва: Creator проти Dependency Injection
  4. Конфлікт GRASP та SOLID: Жорстока реальність
  5. Еволюція складності: “Гітарний ефект”
  6. 🔑 Висновки розділу

Розділ 13. Controller (Контролер): Перша лінія оборони

  1. Що таке System Event (Системна подія)?
  2. Ізоляція багатопоточності: “Хвилеріз”
  3. Антипатерн: Роздутий контролер (Bloated Controller)
  4. Два різновиди контролерів (Facade vs Use-Case)
  5. 🔑 Висновки розділу

Розділ 14. Low Coupling та High Cohesion: Інь і Янь архітектури

  1. Low Coupling: Ефект Метелика та “Монолітність”
  2. High Cohesion: Смітник чи Інструмент?
  3. Доводимо ідеал до абсурду
  4. Кейс YouTube: Коли реальність б’є теорію
  5. Місток до майбутнього: GRASP проти SOLID
  6. 🔑 Висновки розділу

Розділ 15. Polymorphism: Вбивця IF/ELSE

  1. Вступна проблема: Життя на сходинках
  2. “Як роблять джуни”: Жах видалення
  3. Рішення: Поліморфізм як архітектурний патерн
  4. Коли “паттернізм головного мозку” вбиває проєкти
  5. 🔑 Висновки розділу

Розділ 16. Pure Fabrication: Чиста Вигадка (або чому в реальному світі немає Менеджерів і Хелперів)

  1. Конфлікт ООП та Реальності
  2. Компроміс заради метрик: Суть патерну
  3. “Як роблять джуни”: Темний бік вигадок (Utils та Helpers)
  4. Лікування хелперів
  5. Резюме
  6. 🔑 Висновки розділу

Розділ 17. Indirection: Посередник, що Розв’язує Руки (або чому один інтерфейс дорівнює нулю копіпасту)

  1. Вступна проблема: Вася, Маша і Вічний Баг
  2. Рішення: Посередник між двома класами
  3. Термінологічне Пекло: Indirection, DIP, IoC та DI
  4. Суперсила: Interception (Перехоплення)
  5. Тонкощі та Trade-offs: Коли вводити інтерфейси?
  6. Резюме
  7. 🔑 Висновки розділу

Розділ 18. Protected Variations: Як Локалізувати Вибух (або стратегія виживання у світі, де ТЗ змінюється щодня)

  1. Неминучість Змін та Одна Неприємна Правда
  2. Механіка: Два Кроки до Виживання
  3. Axis of Change — Поняття, Яке Буде Переслідувати Вас до Кінця Книги
  4. Protected Variations і OCP — Батько і Син
  5. Антипатерн: Не Будьте Вангою
  6. Резюме та Прощання з GRASP
  7. 🔑 Висновки розділу

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

Розділ 19. Вступ до SOLID та Принцип SRP (Або чому програми гниють і як знайти Вісь Змін)

  1. «Як роблять джуни»: Міф про «одну дію»
  2. Рішення: Осі змін та Актори
  3. Прагматизм: Коли ми свідомо порушуємо SRP
  4. 🔑 Висновки розділу

Розділ 20. OCP: Відкриті для розширення, закриті для змін (або як додавати фічі, не ламаючи старий код)

  1. «Як роблять джуни»: Антипатерн Хардкодингу
  2. Рішення: Два шляхи OCP
  3. Тонкощі та Trade-offs: Пастка Soft-coding
  4. Прагматизм: Коли правила ламаються
  5. 🔑 Висновки розділу

Розділ 21. LSP: Принцип підстановки Лісков (або чому компілятор вас не врятує)

  1. Синдром Миколи: Коли формальність вбиває логіку
  2. Design by Contract (Проєктування за контрактом)
  3. Математика проти ООП: Проблема Квадрата і Прямокутника
  4. Як виявити архітектурний «бруд» (порушення LSP)
  5. LSP і Duck Typing: «Якщо це качка — то і плавати теж зобов’язана»
  6. 🔑 Висновки розділу

Розділ 22. ISP: Інтерфейс належить клієнту (або чому оператору не можна давати «червону кнопку»)

  1. Чому нас вчили зводити все в один «універсальний» інтерфейс
  2. «Дедлайн на вчора» і кнопка Extract Interface
  3. Різати, не чекаючи перитоніту: рольові інтерфейси
  4. Коли ISP виходить за межі коду: REST і мобільна розробка
  5. ISP і качина типізація: навіть качці не завжди потрібні всі її функції
  6. ISP головного мозку (коли доводять до абсурду)
  7. ISP і SRP: два брати-акробати
  8. Місток до DIP
  9. 🔑 Висновки розділу

Розділ 23. DIP: Бізнес не повинен знати про MySQL

  1. Коли бізнес-логіка напряму залежить від MySQL
  2. Що реально означає Dependency Inversion Principle
  3. Бізнес визначає контракт, а не інфраструктура
  4. Адаптери інфраструктури: деталі, які можна міняти
  5. Чому з DIP тести стають коротшими і дешевшими
  6. Де не треба вигадувати зайві інтерфейси
  7. Коротко про шари, щоб ми говорили однією мовою
  8. Як DIP зв’язується з GRASP-принципами
  9. 🔑 Висновки розділу

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

Розділ 24. Вступ до GoF: Патерни як інструменти, а не релігія

  1. Чому ми прийшли до GoF лише тепер
  2. Патерни 1994 року у реаліях 2026
  3. Як пройти всі 23 патерни без втрати практичності
  4. Де DI-контейнер закриває питання, а де — ні
  5. Rule of Three: коли патерн справді потрібен
  6. Класифікація GoF без фанатизму
  7. Що далі: Singleton
  8. 🔑 Висновки розділу

Розділ 25. Singleton (Одинак): Чому глобальний стан вбиває ваші тести

  1. Класична реалізація та багатопотоковий жах
  2. Ілюзія безпеки: пастка Double-Checked Locking
  3. Чому класичний Singleton — це Антипатерн?
  4. Сучасне рішення: DI-контейнер як «Великий Сінглтон»
  5. Специфіка PHP: Сінглтон живе одне життя (запит)
  6. Специфіка Node.js та Python: безкоштовні сінглтони
  7. Мовні «чіт-коди»: Kotlin, Go, Ruby та Rust
  8. Патерн Monostate (коли об’єктів багато, а стан один)
  9. Патерн Multiton (коли одного об’єкта замало)
  10. Singleton і Функціональне програмування (FP)
  11. А якщо у мене немає DI-контейнера? (Pure DI)
  12. Що далі: перехід до фабрик
  13. 🔑 Висновки розділу

Розділ 26. Factory Method та Abstract Factory: Як створювати об’єкти без архітектурного самогубства

  1. Проблема, яку вирішують фабрики
  2. Класичний GoF Factory Method: учбова схема, яку в продакшені фактично не пишуть
  3. Робочий варіант №1: Simple Factory
  4. Робочий варіант №2: Static Factory Method у самому класі
  5. 2026 рік: DI-контейнери вже працюють фабрикою для Injectables
  6. Лямбди як фабрики: менше бойлерплейту
  7. Коли який варіант брати
  8. Динамічна типізація: фабрики без класів
  9. Як не влетіти в overengineering
  10. Музейна хвилинка: Abstract Factory
  11. Що далі: Prototype та Object Pool
  12. 🔑 Висновки розділу

Розділ 27. Prototype та Object Pool: Клони атакують і коробка з інструментами

  1. Як роблять джуни: Антипатерн “Кілометри сеттерів”
  2. Патерн Prototype: Клонування замість конструювання
  3. Диявол у деталях: Поверхневе vs Глибоке копіювання
  4. Патерн Object Pool: Коробка з інструментами
  5. 🔑 Висновки розділу

Розділ 28. Builder: Порятунок від конструкторів-монстрів

  1. Як це описано в GoF (і чому це мертво)
  2. Як це роблять нормальні люди (Fluent Builder)
  3. Мовні реалії 2026 року
  4. Коли все ж виносити Builder в окремий клас?
  5. Builder + Factory Method: Ідеальний симбіоз
  6. 🔑 Висновки розділу

Ücretsiz örnek bölümleri alın

Click the buttons to the right to get the free sample in PDF or EPUB, or read the sample online here

Leanpub Önkoşulsuz, Risksiz, %100 Mutluluk Garantilidir

Leanpub'tan yaptığınız alışverişlerde, 60 günlük sürede %100 iade garantisi mevcut, bunun için sadece iki tıklama yeterli. İade talepleri elden işlenmektedir, aktifleşmesi birkaç gün alabilir. Detaylar için (ingilizce) kullanım sözleşmesini okuyunuz.

10$ değerinde bir satıştan 8$, 20$ değerinde bir satıştan 16$ kazanın

7,99$ veya üzeri satışlarda %80 telif, 0,99$ ile 7,98$ arasındaki satışlarda 50 sent sabit ücret düşülerek %80 telif ödüyoruz. 10$'lık bir satıştan 8$, 20$'lık bir satıştan 16$ kazanıyorsunuz. Yani, kitabınızın iade edilmemiş 5000 kopyasını 20$'dan satarsak, 80.000$ kazanacaksınız.

(Evet, bazı yazarlar Leanpub'da bundan çok daha fazlasını kazandılar.)

Gerçekte, yazarlar Leanpub'da yazarak, yayınlayarak ve satarak 14 milyon dolardan fazla kazandılar.

Leanpub'da yazmak hakkında daha fazla bilgi edinin

Ücretsiz Güncellemeler. DRM İçermez.

If you buy a Leanpub book, you get free updates for as long as the author updates the book! Many authors use Leanpub to publish their books in-progress, while they are writing them. All readers get free updates, regardless of when they bought the book or how much they paid (including free).

Most Leanpub books are available in PDF (for computers), EPUB (for phones and tablets) and MOBI (for Kindle). The formats that a book includes are shown at the top right corner of this page.

Finally, Leanpub books don't have any DRM copy-protection nonsense, so you can easily read them on any supported device.

Leanpub'ın e-kitap formatları ve bunları nerede okuyabileceğiniz hakkında daha fazla bilgi edinin

Leanpub üzerinde Yazın ve Yayımlayın

Authors and publishers use Leanpub to publish amazing in-progress and completed ebooks, just like this one. You can use Leanpub to write, publish and sell your book as well! Leanpub is a powerful platform for serious authors, combining a simple, elegant writing and publishing workflow with a store focused on selling in-progress ebooks. Leanpub is a magical typewriter for authors: just write in plain text, and to publish your ebook, just click a button. It really is that easy.

Leanpub üzerinde nasıl yazabileceğinizi öğrenin
HTTPS · leanpub.com
← Home