Architecture

Як робиться backup і restore?;

технічна архітектура і DevOps

Практична роль: infrastructure architecture відповідає на питання: “Де й як живе наша платформа?”

Monolithic architecture — підхід, у якому застосунок розгортається як один ключовий блок.; Вона має бути достатньою для задачі, зрозумілою для команди, чесною щодо trade-offs і готовою до змін.; ADR зазвичай містить:

хаотичні залежності;
логіка розкидана всюди;
немає меж модулів;
будь-яка зміна ламає інші частини;
немає документації;
тестів мало або немає;
дублювання;
багато “тимчасового” коду;
ніхто не розуміє всю систему.;

Backend architecture описує серверну частину застосунку.; Практична роль: ADR пояснює не лише “що ми обрали”, а й “чому ми так зробили”.;== Database Architecture ==

Стартап MVP

Decision: Use PostgreSQL

Воно знає тільки порти.;

Чи зрозуміє цю архітектуру команда?;

Reliability — здатність системи працювати правильно протягом часу.; Якщо розбити хаос на 20 сервісів, вийде distributed chaos.; Вимірювання краще за здогадки.; істотно: frontend — це не “без ускладнень кнопки”.; * вимоги;

обмеження;
інтеграції;
технології;
security;
cost;
scalability;
support;
deployment;
risks;
trade-offs;
compatibility із наявними системами.; Не кожному застосунку потрібна технічна архітектура рівня глобального банку.; Приклади подій:

Приклад checklist для архітектури

Практична роль: observability — це світло в машинному відділенні.; Infrastructure architecture описує середовище, в якому функціонує застосунок.; Поганий моноліт — це хаос.;

Software architecture — це високорівнева структура програмної системи.; The product is early-stage.; + Clear internal boundaries

Критично: underengineering має змогу оперативно дати MVP, але якщо програмний продукт виживе, команда почне платити відсотки по технічному боргу.;

- Monitoring

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Під час review дивляться на:

* authentication;
* authorization;
* identity management;
* encryption;
* network segmentation;
* secrets management;
* audit logs;
* threat modeling;
* secure coding;
* vulnerability management;
* least privilege;
* incident response;
* data protection;
* compliance.;</div>
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
'''істотно:''' layered architecture корисна, але не треба створювати шари лише з цієї причини, що “так прийнято”.; - CI/CD pipeline
</div>

=== Real-time application ===

переважні аспекти:

Корисні речі:

* presentation layer;
* application layer;
* domain layer;
* data access layer;
* infrastructure layer.; Небезпечний борг — той, який ніхто не бачить.;</div>

'''Modular monolith''' — моноліт, розділений на чіткі внутрішні модулі.;</div>

Інтеграції можуть бути через:

Observability охоплює:

* billing;
* users;
* orders;
* inventory;
* notifications;
* reporting;
* payments;
* admin.; OrderCreated

'''Cloud architecture''' описує, як платформа побудована в хмарі.;</div>
<syntaxhighlight lang="text">

Вона охоплює:

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Як платформа масштабується?; '''Практична роль:''' технічна архітектура має масштабувати не тільки комп’ютери, а й людей.; Поганий контракт змушує страждати всі системи, які від нього залежать.; Legacy має змогу мати:
технічна архітектура не є собою без ускладнень “красивою схемою”.; '''Maintainability''' — здатність системи без зайвих зусиль підтримувати й змінювати.; Це бізнес-рішення з технічними наслідками.;== Cloud Architecture ==
'''Практична роль:''' API — це архітектурний контракт.; Це про рішення для бізнесу, які дозволяють системі жити, змінюватися й залишатися зрозумілою людям, які її будують.;== Коли потрібна технічна архітектура ==

{{SEO
|title=Architecture — архітектура в програмуванні, software architecture, системному дизайні, застосунках і технологіях
|description=Architecture — Wiki-стаття про архітектуру як структуру системи, принципи організації компонентів, зв’язків, рішень і обмежень. Розглянуто software architecture, system architecture, application architecture, enterprise architecture, cloud architecture, monolith, modular monolith, microservices, layered architecture, event-driven architecture, clean architecture, API, database, scalability, security, DevOps, переваги, ризики, цікаві факти і хороші практики.
|keywords=Architecture, архітектура, software architecture, system architecture, application architecture, enterprise architecture, cloud architecture, solution architecture, system design, monolith, modular monolith, microservices, layered architecture, clean architecture, hexagonal architecture, event-driven architecture, API architecture, database architecture, scalability, reliability, security architecture
|alternativeTo=хаотична розробка без структури; spaghetti code; big ball of mud; випадкове з’єднання сервісів; архітектура без документації; overengineering; premature microservices; ручні інтеграції без API; системи без ownership; застосунки без scalability, security і maintainability плану
}}

* UI;
* business logic;
* data access;
* authentication;
* admin panel;
* background jobs;
* API;
* integrations.; # ADR: Use modular monolith for first production version

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

'''Небезпека:''' найгірша технічна архітектура часто виглядає дуже “професійно” на старті, але не відповідає реальним людям, бюджету й задачі.;</div>

Solution architect зазвичай думає про:

</div>

* зрозумілої структури;
* модульності;
* тестів;
* документації;
* code review;
* простих залежностей;
* хороших назв;
* стабільних API;
* низького coupling;
* контрольованого technical debt.; Ціна
<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
Які зовнішні інтеграції?; '''Практична роль:''' цей checklist сприяє не звести архітектуру лише до вибору framework або cloud provider.; переважні аспекти:

* має змогу стати надто механічною;
* іноді створює зайві шари;
* погано спроєктований service layer має змогу перетворитися на “мішок логіки”.; '''Практична порада:''' технічна архітектура потрібна не тоді, коли хочеться красиву діаграму, а тоді, коли неправильні рішення для бізнесу стають дорогими.; Frontend architecture важлива, бо великий frontend має змогу стати таким самим складним, як backend.; Side components:

* незалежний deployment;
* scaling окремих сервісів;
* технологічна гнучкість;
* автономія команд;
* краща ізоляція доменів.; У software engineering вона визначає, як компоненти взаємодіють, де живуть інформаційні дані, як працюють API, security, deployment, monitoring, scalability і супровід.;== Microservices Architecture ==
'''Application architecture''' — технічна архітектура конкретного застосунку.; Часто це ознака зрілості.; Це означає, що команда менше керує ними напряму.; '''Scalability''' — здатність системи витримувати зростання навантаження.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

== Приклад простої web architecture ==

== C4 Model ==

'''Microservices architecture''' — підхід, у якому платформа складається з малих незалежних сервісів, що взаємодіють через API або повідомлення.;<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

* entities;
* use cases;
* interface adapters;
* frameworks and drivers;
* dependency inversion;
* boundaries;
* testable business rules.; Без нього команда здогадується, а не знає.; '''Technical debt''' — наслідок рішень, які спрощують життя зараз, але можуть ускладнити майбутні зміни.; Потрібні integration architecture, data governance, security policies, audit logs, high availability, compliance і супровід legacy-систем.; PaymentReceived

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
'''Проста різниця:''' enterprise architecture дивиться на всю організацію, а solution architecture — на конкретне рішення для бізнесу в межах цієї організації.;</div>
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Serverless має змогу включати:

== Event-Driven Architecture ==

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

* servers;
* containers;
* Kubernetes;
* load balancers;
* networking;
* DNS;
* storage;
* secrets;
* CI/CD;
* monitoring;
* logging;
* backups;
* disaster recovery;
* firewalls;
* cloud accounts;
* environments.; * [[Software Architecture]]
* [[System Architecture]]
* [[Application Architecture]]
* [[Enterprise Architecture]]
* [[Cloud Architecture]]
* [[Solution Architecture]]
* [[System Design]]
* [[Monolith]]
* [[Modular Monolith]]
* [[Microservices]]
* [[Layered Architecture]]
* [[Clean Architecture]]
* [[Hexagonal Architecture]]
* [[Event-Driven Architecture]]
* [[CQRS]]
* [[Event Sourcing]]
* [[API]]
* [[Database]]
* [[DevOps]]
* [[CI/CD]]
* [[Scalability]]
* [[Reliability]]
* [[Security Architecture]]
* [[Observability]]
* [[Technical Debt]]
* [[ADR]]
* [[C4 Model]]
* [[Документація]]

'''Integration architecture''' описує, як платформа взаємодіє з іншими системами.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

<syntaxhighlight lang="text">

* технічна архітектура існує в кожній системі, навіть якщо її ніхто не планував.;</div>
== Monolithic Architecture ==

</div>

'''Проста думка:''' Agile-архітектура — це не “архітектури немає”, а “технічна архітектура розвивається разом із продуктом”.; * microservices для маленького MVP;
* Kubernetes без потреби;
* багато абстракцій без реальних сценаріїв;
* складний event bus для простого CRUD;
* десятки сервісів без команди DevOps;
* надто складна CI/CD схема;
* технічна архітектура “на майбутнє”, яке не настало.; Архітектурні якості кажуть, наскільки добре вона це робить у реальному житті.; технічна архітектура — це не пошук “ідеального”, а вибір прийнятних trade-offs.; '''Критично:''' microservices не лікують поганий дизайн.; '''API architecture''' описує, як системи спілкуються між собою.; Software architecture охоплює:
== Event Sourcing ==
'''Architecture review''' — перевірка важливого рішення для бізнесу або дизайну перед реалізацією.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''Практична порада:''' CQRS не потрібен для кожного CRUD-застосунку.;== Архітектурні якості ==
</div>
 ↓ HTTP/JSON
'''Практична роль:''' strangler pattern сприяє модернізувати стару систему без ризикового “big bang rewrite”.; '''істотно:''' спрощення архітектури — це не крок назад.;== Висновок ==

</div>

</div>

<syntaxhighlight lang="text">

* commands змінюють стан;
* queries читають стан;
* read model має змогу відрізнятися від write model.; Requirements may change quickly.;<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

* починати з модної технології, а не з вимог;
* робити microservices для маленького проєкту;
* не думати про інформаційні дані;
* ігнорувати security;
* не мати backup;
* не мати логів;
* не документувати рішення для бізнесу;
* створювати занадто багато абстракцій;
* плутати архітектуру з папками в коді;
* не враховувати команду;
* копіювати архітектуру великої компанії для маленького продукту;
* не планувати deployment;
* не думати про rollback;
* ігнорувати performance до першої аварії;
* вважати, що діаграма автономно означає хорошу систему.; Поширені architectural patterns:

* cold starts;
* vendor lock-in;
* складніше локальне тестування;
* обмеження runtime;
* складніша observability;
* не всі workloads підходять.; '''Проста аналогія:''' client просить, server виконує або відповідає.;== Коли архітектуру краще спростити ==
== Security Architecture ==
Application Services

<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">

технічна архітектура складається з рішень.; Це платформа, яку важко змінювати без ризику.; Clean architecture часто має:
Enterprise architecture охоплює:
Архітектурне мислення потрібне, коли:

'''Frontend architecture''' описує структуру клієнтської частини застосунку.; The team is small.; * Хороша технічна архітектура не завжди помітна користувачу, але користувач системи оперативно відчує її відсутність через помилки, повільність і нестабільність.; Database

* простіший deployment, ніж microservices;
* зрозумілі межі;
* менше network complexity;
* легше тестувати;
* можна поступово виділити сервіс, якщо справді потрібно;
* підходить для середніх продуктів.; Не варто обирати його лише з цієї причини, що він звучить красиво.; We need fast delivery, simple deployment and clear module boundaries.;</div>
Title: Use PostgreSQL as primary database

</div>

</div>

* починати із вимог і обмежень;
* розуміти бізнес-цілі;
* обирати найпростішу достатню архітектуру;
* документувати важливі рішення для бізнесу через ADR;
* малювати діаграми, які команда реально використовує;
* планувати security з початку;
* думати про observability;
* мати backup і disaster recovery для важливих даних;
* уникати premature microservices;
* тримати модульні межі;
* тестувати critical paths;
* автоматизувати deployment;
* вимірювати performance;
* контролювати technical debt;
* переглядати архітектуру з ростом продукту.; переважні аспекти modular monolith:
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>

== Client-Server Architecture ==

MVP зазвичай не потребує:

* платформа росте;
* є собою кілька команд;
* є собою важливі інформаційні дані;
* потрібна безпека;
* потрібна масштабованість;
* є собою інтеграції;
* є собою compliance;
* deployment став складним;
* зміни ламають інші частини;
* performance важливий;
* потрібно планувати довгострокову підтримку;
* програмний продукт стає бізнес-критичним.; * Monolith має змогу бути хорошою архітектурою, якщо він модульний і контрольований.; Для MVP технічна архітектура має бути простою, але не безвідповідальною.; Backend API

'''істотно:''' serverless не означає, що серверів немає.;<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Order status = Paid

Status: Accepted

У програмуванні технічна архітектура часто стає помітною саме тоді, коли вона погана.; Use a modular monolith with separate modules for users, billing, orders and notifications.;</div>

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

* не переписувати все одразу;
* винести нову функціональність поруч;
* перенаправляти частину трафіку;
* поступово замінювати старі частини;
* зменшувати legacy step by step.; Поширені стилі:
</div>

</div>
'''Serverless architecture''' — підхід, у якому команда пише функції або сервіси, а платформа керує значною частиною серверної інфраструктури.; Типова application architecture має змогу мати:

* складніше розділяти відповідальність при рості;
* великий codebase має змогу стати важким;
* deployment усієї системи для однієї зміни;
* ризик сильного coupling;
* складніше масштабувати окремі частини.;</div>
'''Availability''' — доступність системи для користувачів.; * контекст;
* проблему;
* рішення для бізнесу;
* альтернативи;
* наслідки;
* дату;
* статус.; - Single unstructured monolith
Основні переважні аспекти:
== Frontend Architecture ==

</div>

</div>

== Архітектурні патерни ==

* вимоги;
* альтернативи;
* ризики;
* security;
* scalability;
* data model;
* operations;
* cost;
* migration plan;
* rollback;
* observability;
* compatibility;
* impact на команду.; Ознаки:

Які основні компоненти?; '''Критично:''' event sourcing — потужний патерн, але дуже дорогий у складності.; Команда обирає простий modular monolith, PostgreSQL, базовий deployment, logging і backup, щоб оперативно перевірити програмний продукт без зайвої складності.; * Практики application architecture, cloud architecture і enterprise architecture.; Вона описує компоненти, їхні зв’язки, принципи організації, технологічні рішення для бізнесу й важливі trade-offs.;</div>

Як вона розгортається?; істотно: технічна архітектура, яку важко розгортати, буде гальмувати програмний продукт навіть із хорошим кодом.; Microservices можуть мати: Практична роль: C4 model зручний тим, що не змушує показувати всю складність на одній величезній діаграмі.; * використовувати monolith або microservices;

обрати PostgreSQL або document database;
зробити synchronous API або asynchronous messaging;
розділити frontend і backend;
використовувати cloud або self-hosting;
додати cache;
використовувати event-driven architecture;
обрати authentication provider;
розгорнути через containers;
побудувати multi-tenant SaaS;
зберігати файли в object storage.; !; * повна історичний розвиток змін;
auditability;
можливість rebuild state;
корисно для складних доменів.; ↓

Практична роль: system architecture показує не лише код, а всю екосистему, в якій цей код живе.; Поширені помилки: У технічна архітектура передбачено multi-tenant data model, billing, authentication, role-based access control, background jobs, monitoring і CI/CD.; Недоліки:

більша складність;
eventual consistency;
більше коду;
складніша супровід.;

Big Ball of Mud — антипатерн, коли платформа не має зрозумілої структури.; завдяки наявності Перевага: технічна архітектура користувачі можуть перетворити набір файлів, сервісів і баз даних на систему з правилами, межами й зрозумілою логікою.;== Architecture Documentation ==

модулі;
сервіси;
шари;
API;
бази даних;
черги;
кеші;
інтеграції;
deployment;
security;
scalability;
observability;
reliability;
development workflow.;== Architecture Decision Record ==

складність;
versioning подій;
storage growth;
складніший debugging;
потреба в сильній дисципліні.; * functions as a service;
managed databases;
object storage;
event triggers;
API gateway;
queues;
scheduled jobs;
managed authentication.; Практична роль: навіть проста технічна архітектура має показувати не тільки frontend і backend, а й інформаційні дані, безпеку, deployment і спостережуваність.;

менше адміністрування серверів;
autoscaling;
pay-per-use у частині сценаріїв;
швидкий старт;
добра інтеграційні функціональні можливості з cloud events.;== технічна архітектура і технічний борг ==

Maintainability залежить від:

Практична роль: ADR сприяє майбутній команді зрозуміти контекст рішення для бізнесу, а не без ускладнень бачити результат.; Головна думка: технічна архітектура — це не про модні діаграми.; * logs;

metrics;
traces;
alerts;
dashboards;
health checks;
audit logs;
error tracking;
distributed tracing;
business metrics.;== переважні аспекти хорошої архітектури ==

CI/CD;
automated testing;
infrastructure as code;
containers;
environment parity;
rollback;
monitoring;
logging;
deployment frequency;
incident response;
runbooks.;

API server;
database server;
authentication server;
file server;
game server;
backend service.; * технічна архітектура має масштабувати не лише трафік, а й команду, підтримку й бізнес-середовище.; Яку бізнес-задачу вирішує платформа?; Приклад структури:

Хороша технічна архітектура не обов’язково складна.; Насправді вона змінюється разом із продуктом.;

складніша мережа;
distributed transactions;
eventual consistency;
складніший debugging;
більші вимоги до DevOps;
observability стає обов’язковою;
більше operational overhead.;

SaaS-платформа

Context:

зрозумілої структури;
базової безпеки;
backup;
logging;
простого deployment;
функціональні можливості змінювати код;
мінімальної документації;
тестів для критичних сценаріїв.; * Матеріали щодо monolith, modular monolith, microservices, layered architecture, clean architecture, hexagonal architecture і event-driven architecture.; Головна перевага: хороша технічна архітектура зменшує вартість змін.; * має змогу бути надмірною для простих CRUD;
більше файлів і boilerplate;
вимагає дисципліни;
неправильне використання створює overengineering.;

Cloud architecture має змогу включати:

↓

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

Frontend Web App Коли команда росте, технічна архітектура має допомагати людям працювати паралельно.; Моноліт має змогу містити:

enterprise systems;
service contracts;
ESB;
SOAP у legacy-сценаріях;
integration platforms;
reusable business services;
governance.; * достатньою для поточного етапу;
готовою до змін;
не надмірною;
підтриманою тестами;
зрозумілою команді;
документованою через важливі рішення для бізнесу;
пов’язаною з feedback.;== Modular Monolith ==

REST controller;
database repository;
message queue consumer;
payment gateway adapter;
email adapter;
CLI adapter;
test adapter.; Які головні trade-offs?; - Strong module discipline is required

Цікавий факт

Цікаві факти про Architecture

API architecture враховує:

істотно: event-driven architecture добре функціонує, коли команда розуміє асинхронність, повторну доставку, idempotency і спостережуваність.; Context: Need relational data model and transactions

Trade-off

істотно: application architecture має відповідати реальному розміру продукту.; рішення для бізнесу

presentation layer;
application layer;
domain layer;
infrastructure layer;
database layer;
API layer;
integration layer;
background workers;
cache;
monitoring.;

слабше зв’язування компонентів;
добра основа для async workflows;
легше додавати нові реакції;
корисно для масштабних систем.; Вона передбачувано поводиться при збоях і оперативно відновлюється.; * Найважчі архітектурні рішення для бізнесу часто стосуються даних, а не коду.; Але коли з’являються нові функції, інтеграції, користувачі, помилки, команда й deadlines, погана структура починає “кричати”: зміни ламають інші частини, баги важко знайти, deployment страшний, а одна маленька правка займає тиждень.;</syntaxhighlight>

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

application portfolio;
data flows;
integration landscape;
security policies;
compliance;
governance;
legacy systems;
cloud strategy;
identity management;
enterprise platforms;
technology standards;
roadmaps.;

Backup істотно: висока availability коштує грошей і складності.; технічна архітектура потребує документації, але документація має бути живою й корисною.; * component structure;

state management;
routing;
design system;
API layer;
forms;
validation;
caching;
error handling;
accessibility;
performance;
build tools;
testing.;== Software Architecture ==

Scalability

технічна архітектура і бізнес-середовище

Проста думка: функції кажуть, що платформа робить.; * Матеріали щодо architecture decision records, C4 model, domain-driven design, technical debt і software maintainability.; OrderMarkedAsPaid

Hexagonal Architecture

технічна архітектура має враховувати: Важливі якості:

Модернізація legacy

Reliability

Context;
Container;
Component;
Code.; Observability — здатність розуміти, що відбувається всередині системи, за зовнішніми сигналами.;</syntaxhighlight>

складніше debug;
eventual consistency;
потреба в message broker;
duplicate events;
ordering problems;
складніша observability.;

Недоліки і ризики архітектури

Strangler Fig Pattern

Недоліки:

Big Ball of Mud

API;
business logic;
database access;
authentication;
authorization;
background jobs;
integrations;
caching;
queues;
transactions;
logging;
monitoring;
deployment.; Architecture Decision Record або ADR — короткий документ, який фіксує важливе архітектурне рішення для бізнесу.;

Підказка: перед вибором архітектури варто описати не тільки функції, а й навантаження, інформаційні дані, команду, бюджет, ризики й очікуваний темп змін.; Strangler Fig Pattern — підхід до поступової заміни legacy-системи.; Приклади server:

Service-Oriented Architecture

architecture diagram;
C4 model;
ADR;
sequence diagram;
deployment diagram;
data flow diagram;
API documentation;
runbook;
threat model;
decision log;
onboarding guide.;

algorithms;
database queries;
indexes;
caching;
network latency;
serialization;
concurrency;
frontend bundle size;
resource usage;
infrastructure;
third-party APIs.; * Microservices часто вирішують організаційні проблеми не менше, ніж технічні.; |-

| Microservices | Незалежне масштабування й автономні команди | Складніша інфраструктура, мережа й observability |- | Monolith | Простий старт і deployment | Складніше масштабувати окремі частини при рості |- | Cache | Швидше читання | Ризик stale data і складність invalidation |- | NoSQL | Гнучка модель даних | має змогу бути складніше з joins і транзакційністю |- | Serverless | Менше адміністрування серверів | Cold starts, vendor lock-in і обмеження runtime |}

Infrastructure Architecture

Недоліки:

технічна архітектура залежить не лише від технологій, а й від команди.; Команда використовує strangler fig pattern, поступово переносить частини системи в нові модулі або сервіси, не зупиняючи бізнес-середовище.; Underengineering — недостатня архітектурна увага, коли платформа росте без структури.; Приклади client:

Вона охоплює:

UserRegistered;
OrderCreated;
PaymentReceived;
EmailSent;
ProductUpdated;
InvoiceGenerated.; Потрібно враховувати:

'''Hexagonal architecture''' або '''Ports and Adapters''' — підхід, де core application спілкується із зовнішнім світом через порти й адаптери.;== Underengineering ==
Core logic не знає деталей PostgreSQL, Stripe, HTTP або RabbitMQ.; '''CQRS''' або '''Command Query Responsibility Segregation''' — патерн, який розділяє операції запису й читання.;== Overengineering ==

</div>

* окремі codebases;
* окремі deployments;
* власні бази даних;
* незалежні команди;
* API contracts;
* service discovery;
* observability;
* distributed tracing;
* message brokers.; * складних microservices;
* надмірної abstraction;
* multi-region deployment;
* складної event sourcing системи;
* Kubernetes без потреби;
* enterprise governance з першого дня.; '''Overengineering''' — надмірно складна технічна архітектура для простої задачі.; Consequences: Strong SQL and ACID, but need DBA knowledge and backup strategy

System architecture має змогу включати:

== Solution Architecture ==

* schema design;
* normalization;
* indexes;
* transactions;
* replication;
* partitioning;
* backup;
* migrations;
* access control;
* data retention;
* audit logs;
* read/write patterns;
* consistency model.; '''істотно:''' патерн — це не наказ, а інструмент.; '''Практична роль:''' SOA була важливим етапом у розвитку enterprise integration ще до масової популярності microservices.; У software engineering технічна архітектура сприяє відповісти на питання:
== технічна архітектура і масштабування команди ==
</div>

переважні аспекти:

<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

<syntaxhighlight lang="text">

* frontend applications;
* backend services;
* databases;
* cache;
* message queues;
* object storage;
* CDN;
* authentication provider;
* monitoring;
* logging;
* load balancers;
* external APIs;
* cloud services;
* CI/CD;
* backup systems.; '''Практична порада:''' моноліт не є собою поганим словом.; '''Практична порада:''' не треба масштабувати все одразу.; '''Проста аналогія:''' hexagonal architecture — це платформа з розетками: всередині є собою стабільна логіка, а зовнішні пристрої підключаються через адаптери.; Вона описує, як організовані frontend, backend, інформаційні дані, бізнес-логіка, API, authentication, background jobs і deployment.; Спочатку потрібно знайти реальне bottleneck.; Alternatives:

</div>

== технічна архітектура і команда ==

'''Помилка:''' думати, що технічна архітектура — це те, що роблять один раз на старті.; Він обирає, які проблеми платформа готова прийняти.;</div>

* публікувати events;
* підписуватися на events;
* обробляти events asynchronously;
* реагувати без прямого виклику іншого сервісу.; Вона охоплює:

<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

<syntaxhighlight lang="text">

* uptime;
* redundancy;
* load balancers;
* database failover;
* multi-region design;
* deployment strategy;
* incident response;
* monitoring;
* rollback;
* dependency health.;== технічна архітектура і Agile ==
'''Event-driven architecture''' — технічна архітектура, де компоненти взаємодіють через події.;<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
== Тематичні мітки ==
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

== технічна архітектура і legacy ==

== Availability ==

Ідея:

технічна архітектура застосовується в багатьох сферах:
!; коду: дороги забезпечується через '''Проста аналогія:''' software architecture — це план міста; додатково реалізовано райони, правила руху, комунікації й місця, де не варто будувати хаотично.;<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">
Приклади адаптерів:
'''Основна ідея:''' технічна архітектура — це відповідь на питання: “Як платформа влаштована так, щоб її можна було будувати, змінювати, масштабувати й підтримувати?”

'''Практична роль:''' Clean Architecture корисна там, де бізнес-правила важливіші й довговічніші за конкретний framework.; Види масштабування:

Зовнішні деталі залежать від внутрішньої бізнес-логіки,

істотно: performance-проблема часто не там, де здається.; Перевага

Enterprise Architecture

Database architecture описує, як інформаційні дані організовані й зберігаються.; Можливі проблеми:

versioning;
authentication;
rate limits;
pagination;
error format;
documentation;
backward compatibility;
idempotency;
observability;
security.; Яке очікуване навантаження?; Погана технічна архітектура має змогу бути як занадто хаотичною, так і занадто “розумною” без реальної потреби.;== Layered Architecture ==

Performance залежить від:

Загальний характеристика

Event sourcing — патерн, у якому стан системи відновлюється з послідовності подій.; переважні аспекти:

Див.; додатково

Практична думка: технічна архітектура MVP має допомогти оперативно вчитися, але не створити технічну пастку вже на старті.; Decision:

monolith;
modular monolith;
microservices;
layered architecture;
clean architecture;
hexagonal architecture;
event-driven architecture;
CQRS;
event sourcing;
serverless;
microkernel;
pipe-and-filter;
broker pattern;
strangler fig pattern;
shared-nothing architecture.; а не навпаки.;

- Scaling individual modules independently will be harder

Типові шари:

неправильні межі модулів;
відсутність тестів;
слабку модель даних;
hardcoded інтеграції;
відсутність observability;
непродуманий deployment;
хаотичні залежності;
ручні процеси;
застарілі технології.;

Де зберігаються інформаційні дані?; - Serverless-only architecture Client-server architecture — класична модель, де client надсилає запити, а server обробляє їх і повертає відповідь.; Його потрібно обирати під проблему, а не під моду.; Часто найкраща технічна архітектура — найпростіша, яка чесно закриває вимоги.; - Logging

істотно: технічна архітектура даних часто визначає майбутнє продукту сильніше, ніж вибір frontend framework.; Критично: помилки в database architecture часто найдорожчі, бо інформаційні дані важче змінювати, ніж код.; платформа зберігає історію: Data architecture описує, як інформаційні дані збираються, зберігаються, обробляються, передаються й захищаються.; * web browser;

mobile app;
desktop app;
CLI tool;
IoT device.;

Clean Architecture

Найлюдяніший факт: технічна архітектура — це спосіб домовитися з майбутнім: “Ми знаємо, що все зміниться, з цієї причини будуємо так, щоб ці зміни нас не зламали”.;

Найпрактичніший факт: modular monolith часто є собою кращим першим вибором, ніж microservices, якщо команда ще не має реальної потреби в розподіленій архітектурі.; Enterprise architecture описує технологічну й бізнесову структуру великої організації.;

Головна думка: архітектор не без ускладнень обирає технології.; Service-Oriented Architecture або SOA — підхід, у якому платформа складається з сервісів, що надають бізнес-функції через стандартизовані інтерфейси.; технічна архітектура має змогу включати WebSocket gateway, message broker, cache, horizontal scaling і distributed tracing.; Якщо security не врахована в архітектурі, потім її важко й дорого прикручувати.; C4 сприяє показати систему різним аудиторіям:

</syntaxhighlight>

maintainability;
scalability;
reliability;
availability;
security;
performance;
usability;
testability;
deployability;
observability;
portability;
resilience;
cost efficiency;
extensibility.; ↓

Основна ідея: Рекомендовано:

+ Easier local development

Недоліки:

time to market;
cost of change;
reliability;
customer trust;
compliance;
scaling;
hiring;
operations cost;
vendor lock-in;
product flexibility;
risk management.; Часто краще стабілізувати, покрити тестами, документувати й поступово замінювати.; Controller → Service → Repository → Database

DevOps пов’язує архітектуру з delivery, operations і reliability.;== Data Architecture ==

Clean architecture — підхід, у якому бізнес-логіка ізольована від frameworks, database, UI й зовнішніх сервісів.;

Приклад: Помилка: хороша технічна архітектура не дорівнює максимальній складності.; Architecture — це структура й логіка організації системи.; * які основні компоненти системи;

хто за що відповідає;
як компоненти взаємодіють;
де зберігаються інформаційні дані;
як платформа обробляє помилки;
як функціонує authentication і authorization;
як платформа масштабується;
як її тестувати;
як її розгортати;
як її моніторити;
як змінювати без хаосу.;== System Architecture ==

Agile не означає відсутність архітектури.; Поки платформа маленька, майже будь-який код здається нормальним.; * Практики DevOps, CI/CD, observability, reliability engineering, security architecture і data architecture.;

добре тестується;
бізнес-логіка менше залежить від framework;
легше міняти infrastructure;
корисна для складних доменів.;

істотно: architecture review має допомагати ухвалювати рішення для бізнесу, а не бути бюрократичною пасткою.; Найлюдяніший факт: хороша технічна архітектура — це не та, яка виглядає найрозумнішою на діаграмі, а та, з якою команда має змогу спокійно працювати через рік.; Вона охоплює: Замість зберігати лише поточний стан: істотно: інтеграції ламаються не тільки через код, а й через зміни API, мережу, ліміти, інформаційні дані й людські процеси.; Ідея:

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

простий старт;
простіший deployment;
легше розробляти малим командам;
прості транзакції;
менше мережевих викликів;
легше локально запускати.; Це набір рішень, які впливають на швидкість розробки, стабільність, безпеку, продуктивність, вартість підтримки й здатність системи змінюватися з часом.; Він корисний, коли читання й запис справді мають різні потреби.; * Найкраща технічна архітектура для MVP і найкраща технічна архітектура для global-scale product — це майже ніколи не одна й та сама технічна архітектура.;== Приклади сценаріїв використання ==

* Матеріали з software architecture і system design.; User Browser
</div>
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Reliability залежить від:

Недоліки:

'''Критично:''' безпека не має бути “додатком у кінці”.;</div>

* clear module boundaries;
* ownership;
* API contracts;
* coding standards;
* shared libraries;
* documentation;
* test strategy;
* deployment process;
* architecture review;
* platform team у великих організаціях.;<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

* vertical scaling;
* horizontal scaling;
* database scaling;
* caching;
* read replicas;
* sharding;
* asynchronous processing;
* CDN;
* autoscaling;
* load balancing.; Як функціонує rollback?; * легше змінювати систему;
* менше випадкових поломок;
* зрозуміліші межі;
* простіше тестування;
* краща продуктивність;
* краща безпека;
* легше масштабування;
* зрозуміліший deployment;
* швидший onboarding;
* простіша супровід;
* краще керування ризиками;
* легше інтегрувати нові функції;
* менше хаосу в команді.; !; Якщо її не спроєктували свідомо, вона виникла випадково.;</div>
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
== Типові помилки початківців ==
Agile architecture має бути:

'''Trade-off''' — компроміс між перевагами й недоліками.; * слабку документацію;
* відсутні тести;
* застарілі dependencies;
* невідомі бізнес-правила;
* manual deployment;
* tight coupling;
* погану observability;
* важливі production-дані;
* залежність бізнесу.;</div>
'''Layered architecture''' або багатошарова технічна архітектура розділяє систему на шари.; PaymentRequested
'''Практична роль:''' cloud architecture — це не без ускладнень “перенести сервер у хмару”, а використати хмарні сервіси так, щоб платформа була надійною, безпечною й керованою за вартістю.; Компоненти можуть:

== Приклад ADR ==

Що буде складно змінити пізніше?; Ознаки:

* бізнесу — загальний контекст;
* розробникам — контейнери й компоненти;
* технічним командам — деталі реалізації.;== Performance ==

* virtual machines;
* containers;
* Kubernetes;
* serverless functions;
* managed databases;
* object storage;
* CDN;
* load balancers;
* VPC/networking;
* IAM;
* secret managers;
* observability;
* autoscaling;
* backup;
* disaster recovery;
* cost optimization.; У сучасних застосунках frontend часто містить складну бізнес-логіку, стан і інтеграції.; '''Практична роль:''' reliable system не обов’язково ніколи не падає.;<syntaxhighlight lang="text">

* REST;
* GraphQL;
* gRPC;
* WebSocket;
* event APIs;
* webhooks;
* SOAP у legacy-системах.; Модулі можуть бути:

== Maintainability ==
MVP зазвичай потребує:
<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

- Microservices

=== Велика enterprise-система ===

* software architecture;
* system architecture;
* application architecture;
* enterprise architecture;
* cloud architecture;
* solution architecture;
* data architecture;
* security architecture;
* network architecture;
* infrastructure architecture;
* frontend architecture;
* backend architecture;
* mobile architecture;
* DevOps architecture;
* AI/ML architecture.;== Джерела ==

* розмір команди;
* досвід;
* ownership;
* комунікація;
* release process;
* DevOps maturity;
* product uncertainty;
* супровід;
* бюджет;
* compliance;
* швидкість змін.;</div>
'''Solution architecture''' — технічна архітектура конкретного рішення для бізнесу для конкретної бізнес-задачі.; переважні аспекти:
'''Найпрактичніший критерій:''' якщо нова людина в команді не має змогу зрозуміти систему за розумний час, maintainability слабка.; SOA часто асоціюється з:
== Application Architecture ==
== Serverless Architecture ==

</div>

Приклади архітектурних рішень:

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

* operational databases;
* data warehouse;
* data lake;
* ETL/ELT;
* event streams;
* data models;
* schemas;
* data governance;
* data quality;
* lineage;
* privacy;
* access control;
* backup;
* retention policies.; '''Security architecture''' описує, як платформа захищає користувачів, інформаційні дані, інфраструктуру й бізнес-процеси.; Архітектуру оцінюють не лише за функціями, а й за якісними характеристиками.; На availability впливають:

== CQRS ==

<div style="background:#fdecea; border-left:6px solid #e74c3c; padding:12px; margin:12px 0;">

* REST API;
* webhooks;
* message queues;
* file exchange;
* ETL;
* event streaming;
* database replication;
* third-party SDK;
* enterprise service bus;
* iPaaS.; Типові рівні:
технічна архітектура має відповідати бізнес-цілям.; '''істотно:''' кожне архітектурне рішення для бізнесу має ціну.; * overengineering;
* занадто багато шарів;
* передчасні microservices;
* складна інфраструктура без потреби;
* технічна архітектура відірвана від команди;
* документація не відповідає реальності;
* повільні рішення для бізнесу через бюрократію;
* патерни заради патернів;
* vendor lock-in без розуміння;
* security і operations забуті;
* архітектор не слухає розробників.; Добра технічна архітектура часто навпаки виглядає нудно: зрозумілі модулі, передбачувані межі, очевидні залежності, нормальні логи, простий deployment і документація, яку справді читають.;== API Architecture ==
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Хто користувачі?; {| class="wikitable"
Важливі фактори:
== Observability ==

'''Практична роль:''' технічна архітектура — це не лише технічне рішення для бізнесу.; Приклади:

<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

'''істотно:''' legacy не завжди треба переписувати.; технічна архітектура впливає не тільки на технічну якість, а й на швидкість команди, вартість змін і здатність продукту розвиватися.; '''Небезпека:''' Big Ball of Mud часто з’являється не за один день, а через багато маленьких “потім приберемо”.;</div>

* усе в одному файлі;
* немає тестів;
* немає ownership;
* інформаційні дані зберігаються як доведеться;
* немає backup;
* немає monitoring;
* security “потім”;
* немає логування;
* немає меж між модулями;
* немає deployment strategy.;</div>

* оптимізація читання;
* складні доменні сценарії;
* різні моделі для різних задач;
* корисно з event-driven systems.; це спосіб організації складної системи: її частин, зв’язків, правил, обмежень і ключових рішень виступає ключовою рисою '''Architecture''' або '''технічна архітектура'''.; Ідея:
<div style="background:#fef2f2; border-left:6px solid #ef4444; padding:12px; margin:12px 0;">
Недоліки:

'''Практична роль:''' backend architecture визначає, наскільки надійно застосунок обробляє інформаційні дані, правила й інтеграції.; + Simpler deployment

Data architecture охоплює: </syntaxhighlight>

Backend Architecture

Вона охоплює:

технічна архітектура і MVP

- Authentication provider

Як команда побачить помилки?;

Які вимоги до безпеки?;</syntaxhighlight> Status: Accepted

Архітектурні рішення для бізнесу

Головне правило: технічна архітектура має бути достатньою для задачі, зрозумілою для команди й чесною щодо trade-offs.;== Integration Architecture ==

Ознаки:

Хороші практики архітектури

↓

істотно: застаріла архітектурна документація має змогу бути небезпечнішою за її відсутність, бо створює фальшиве розуміння системи.; * Architecture diagram без актуального коду й документації має змогу оперативно стати фантазією.; * retries;

timeouts;
idempotency;
error handling;
authentication;
rate limits;
monitoring;
data mapping;
contract changes.;== Архітектурний огляд ==

Legacy system — це не без ускладнень стара платформа.;</syntaxhighlight>

Недоліки:

error handling;
retries;
timeouts;
monitoring;
testing;
redundancy;
backups;
graceful degradation;
incident response;
failover;
data consistency;
dependency management.; Performance — швидкість і ефективність системи.; Consequences:

Корисні формати:

команда не розуміє систему;
deployment надто складний;
є собою сервіси без реальної причини;
абстракції заважають;
інфраструктура дорожча за користь;
debugging займає надто багато часу;
документація не встигає за реальністю;
MVP ще не підтверджений;
зміни стали повільнішими через архітектуру.; Архітектуру варто спрощувати, якщо:

Архітектурний борг виникає через: переважні аспекти:

Практична роль: enterprise architecture сприяє великій компанії не перетворити сотні систем на некерований клубок інтеграцій.; істотно: технічний борг не завжди поганий, якщо він свідомий і контрольований.; * зрозуміла структура;

проста для навчання;
добре підходить для багатьох CRUD-застосунків;
легше розділяти відповідальність;
зручна для командної роботи.; Маленькому застосунку не завжди потрібна складна enterprise-структура.; C4 model — спосіб опису software architecture через кілька рівнів деталізації.; Він означає, що технічна архітектура має змогу розвиватися поступово.; переважні аспекти:

Вона впливає на:

System architecture описує структуру всієї системи, включно з програмами, серверами, базами даних, мережами, зовнішніми сервісами, користувачами й потоками даних.; Хороший моноліт має змогу бути дуже ефективною архітектурою.; * Architecture