Architecture

Maintainability

</syntaxhighlight>

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

Недоліки: Приклади адаптерів:

Data architecture містить:

конкурентні переваги:

конкурентні переваги хорошої архітектури

System architecture описує структуру всієї системи, включно з програмами, серверами, базами даних, мережами, зовнішніми сервісами, користувачами й потоками даних. Під час review дивляться на:

C4 Model

Monolithic Architecture

Service-Oriented Architecture

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

Основна ідея: Приклад: Критично: event sourcing — потужний патерн, але дуже дорогий у складності.== Event Sourcing ==

складних microservices;
надмірної abstraction;
multi-region deployment;
складної event sourcing системи;
Kubernetes без потреби;
enterprise governance з першого дня.

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

Модулі можуть бути:

Database

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

== Архітектурний огляд ==

* усе в одному файлі;
* немає тестів;
* немає ownership;
* інформаційні дані зберігаються як доведеться;
* немає backup;
* немає monitoring;
* security “потім”;
* немає логування;
* немає меж між модулями;
* немає deployment strategy. Вона передбачувано поводиться при збоях і оперативно відновлюється.<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">
а не навпаки. У сучасних застосунках frontend часто містить складну бізнес-логіку, стан і інтеграції. технічна архітектура потребує документації, але документація має бути живою й корисною. технічна архітектура — це не пошук “ідеального”, а вибір прийнятних trade-offs. * maintainability;
* scalability;
* reliability;
* availability;
* security;
* performance;
* usability;
* testability;
* deployability;
* observability;
* portability;
* resilience;
* cost efficiency;
* extensibility. технічна архітектура впливає не тільки на технічну якість, а й на швидкість команди, вартість змін і здатність продукту розвиватися. Enterprise architecture охоплює:

Практична порада: CQRS не потрібен для кожного CRUD-застосунку. * здатна бути надмірною для простих CRUD;

більше файлів і boilerplate;
вимагає дисципліни;
неправильне використання створює overengineering. * entities;
use cases;
interface adapters;
frameworks and drivers;
dependency inversion;
boundaries;
testable business rules. критично: кожне архітектурне рішення для бізнесу має ціну.

Real-time application

Практична роль: C4 model зручний тим, що не змушує показувати всю складність на одній величезній діаграмі. ADR зазвичай містить: Проста аналогія: hexagonal architecture — це платформа з розетками: всередині виступає як стабільна логіка, а зовнішні пристрої підключаються через адаптери. Architecture Decision Record або ADR — короткий документ, який фіксує важливе архітектурне рішення для бізнесу.== Reliability ==

API architecture враховує:

конкурентні переваги:

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

</syntaxhighlight>

Microservices можуть мати:

критично: serverless не означає, що серверів немає.== Observability ==

Trade-off

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

Загальний SEO-опис

Джерела

Modular Monolith

конкурентні переваги:

Практична роль: навіть проста технічна архітектура має показувати не тільки frontend і backend, а й інформаційні дані, безпеку, deployment і спостережуваність.

Serverless здатна включати: конкурентні переваги:

Коли потрібна технічна архітектура

We need fast delivery, simple deployment and clear module boundaries. Ціна

Clean Architecture

Типові рівні: Критично: microservices не лікують поганий дизайн. * Monolith здатна бути хорошою архітектурою, якщо він модульний і контрольований.== Див. так само ==

Чи зрозуміє цю архітектуру команда? Це бізнес-рішення з технічними наслідками.

algorithms;
database queries;
indexes;
caching;
network latency;
serialization;
concurrency;
frontend bundle size;
resource usage;
infrastructure;
third-party APIs. * 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. Legacy здатна мати:

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

конкурентні переваги:

легше змінювати систему;
менше випадкових поломок;
зрозуміліші межі;
простіше тестування;
краща продуктивність;
краща безпека;
легше масштабування;
зрозуміліший deployment;
швидший onboarding;
простіша технічна підтримка;
краще керування ризиками;
легше інтегрувати нові функції;
менше хаосу в команді. * Architecture diagram без актуального коду й документації здатна оперативно стати фантазією. Controller → Service → Repository → Database

Недоліки:

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

Strangler Fig Pattern

Software architecture — це високорівнева структура програмної системи.

критично: application architecture має відповідати реальному розміру продукту. Недоліки: Вона містить:

У software engineering технічна архітектура оптимізує відповісти на питання: Event sourcing — патерн, у якому стан системи відновлюється з послідовності подій. Вона містить:

Reliability — здатність системи працювати правильно протягом часу. * більша складність;

eventual consistency;
більше коду;
складніша технічна підтримка. Frontend architecture важлива, бо великий frontend здатна стати таким самим складним, як backend. Вона містить:

Які зовнішні інтеграції? * бізнесу — загальний контекст;

розробникам — контейнери й компоненти;
технічним командам — деталі реалізації. Cloud architecture описує, як платформа побудована в хмарі.

Hexagonal architecture або Ports and Adapters — підхід, де core application спілкується із зовнішнім світом через порти й адаптери.

Критично: безпека не має бути “додатком у кінці”.

Які головні trade-offs?</div>

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

Use a modular monolith with separate modules for users, billing, orders and notifications. Він корисний, коли читання й запис справді мають різні потреби. '''Проста думка:''' функції кажуть, що платформа робить.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

Order status = Paid
Потрібно враховувати:
Як команда побачить помилки? Архітектурні якості кажуть, наскільки добре вона це робить у реальному житті. '''Performance''' — швидкість і ефективність системи. Вимірювання краще за здогадки. Software architecture охоплює:

Side components:

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

'''Практична порада:''' технічна архітектура потрібна не тоді, коли хочеться красиву діаграму, а тоді, коли неправильні рішення для бізнесу стають дорогими. ↓ HTTP/JSON

* UI;
* business logic;
* data access;
* authentication;
* admin panel;
* background jobs;
* API;
* integrations. * architecture diagram;
* C4 model;
* ADR;
* sequence diagram;
* deployment diagram;
* data flow diagram;
* API documentation;
* runbook;
* threat model;
* decision log;
* onboarding guide. '''Event-driven architecture''' — технічна архітектура, де компоненти взаємодіють через події. '''Microservices architecture''' — підхід, у якому платформа складається з малих незалежних сервісів, що взаємодіють через API або повідомлення.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
MVP зазвичай потребує:

</div>

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

'''Практична роль:''' Clean Architecture корисна там, де бізнес-правила важливіші й довговічніші за конкретний framework.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
== Application Architecture ==

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

конкурентні переваги:

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

* неправильні межі модулів;
* відсутність тестів;
* слабку модель даних;
* hardcoded інтеграції;
* відсутність observability;
* непродуманий deployment;
* хаотичні залежності;
* ручні процеси;
* застарілі технології. '''Modular monolith''' — моноліт, розділений на чіткі внутрішні модулі.</div>

* простий старт;
* простіший deployment;
* легше розробляти малим командам;
* прості транзакції;
* менше мережевих викликів;
* легше локально запускати. '''критично:''' legacy не завжди треба переписувати. - Scaling individual modules independently will be harder

Як платформа масштабується? '''Availability''' — доступність системи для користувачів. * Context;
* Container;
* Component;
* Code.== Integration Architecture ==
'''Практична роль:''' system architecture показує не лише код, а всю екосистему, в якій цей код живе. * розмір команди;
* досвід;
* ownership;
* комунікація;
* release process;
* DevOps maturity;
* product uncertainty;
* технічна підтримка;
* бюджет;
* compliance;
* швидкість змін. * Найкраща технічна архітектура для MVP і найкраща технічна архітектура для global-scale product — це майже ніколи не одна й та сама технічна архітектура. '''критично:''' performance-проблема часто не там, де здається. * uptime;
* redundancy;
* load balancers;
* database failover;
* multi-region design;
* deployment strategy;
* incident response;
* monitoring;
* rollback;
* dependency health. '''Проста аналогія:''' client просить, server виконує або відповідає. '''критично:''' технічний борг не завжди поганий, якщо він свідомий і контрольований.== Cloud Architecture ==
'''Database architecture''' описує, як інформаційні дані організовані й зберігаються.</div>
== Коли архітектуру краще спростити ==
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

'''критично:''' layered architecture корисна, але не треба створювати шари лише тому, що “так прийнято”. '''Практична роль:''' цей checklist оптимізує не звести архітектуру лише до вибору framework або cloud provider. У програмуванні й технологіях технічна архітектура описує, як застосунок або платформа побудовані, як компоненти взаємодіють, де зберігаються інформаційні дані, як функціонує безпека, як платформа масштабується, розгортається, підтримується й змінюється.</div>
== Архітектурні рішення для бізнесу ==
Можливі проблеми:

'''Frontend architecture''' описує структуру клієнтської частини застосунку. Приклад структури:

'''C4 model''' — спосіб опису software architecture через кілька рівнів деталізації. Не варто обирати його лише тому, що він звучить красиво.== технічна архітектура і технічний борг ==
'''API architecture''' описує, як системи спілкуються між собою.<syntaxhighlight lang="text">

* контекст;
* проблему;
* рішення для бізнесу;
* альтернативи;
* наслідки;
* дату;
* статус.</div>
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

+ Simpler deployment

критично: architecture review має допомагати ухвалювати рішення для бізнесу, а не бути бюрократичною пасткою. Маленькому застосунку не завжди потрібна складна enterprise-структура. Application architecture — технічна архітектура конкретного застосунку. Моноліт здатна містити: Ідея: - Single unstructured monolith Рекомендовано:

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

Хто користувачі?

Alternatives:

Поширені стилі:

- Logging

== Event-Driven Architecture ==

Зовнішні деталі залежать від внутрішньої бізнес-логіки,
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
Reliability залежить від:
'''Головна думка:''' архітектор не без зусиль обирає технології. Поки платформа маленька, майже будь-який код здається нормальним. Це набір рішень, які впливають на швидкість розробки, стабільність, безпеку, продуктивність, вартість підтримки й здатність системи змінюватися з часом.== Availability ==
Clean architecture часто має:

== Serverless Architecture ==

</div>

=== SaaS-платформа ===

* error handling;
* retries;
* timeouts;
* monitoring;
* testing;
* redundancy;
* backups;
* graceful degradation;
* incident response;
* failover;
* data consistency;
* dependency management.<syntaxhighlight lang="text">
На availability впливають:
Поширені помилки:

'''Практична роль:''' SOA була важливим етапом у розвитку enterprise integration ще до масової популярності microservices. ! * billing;
* users;
* orders;
* inventory;
* notifications;
* reporting;
* payments;
* admin. Які основні компоненти?<syntaxhighlight lang="text">
</div>
- Strong module discipline is required

Команда обирає простий modular monolith, PostgreSQL, базовий deployment, logging і backup, щоб оперативно перевірити ERP-продукт без зайвої складності. * Матеріали з software architecture і system design.</div>

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

== Висновок ==

</div>

Архітектуру варто спрощувати, якщо:

* UserRegistered;
* OrderCreated;
* PaymentReceived;
* EmailSent;
* ProductUpdated;
* InvoiceGenerated. технічна архітектура здатна нашкодити, якщо її робити неправильно. The product is early-stage. The team is small. Приклади архітектурних рішень:

* operational databases;
* data warehouse;
* data lake;
* ETL/ELT;
* event streams;
* data models;
* schemas;
* data governance;
* data quality;
* lineage;
* privacy;
* access control;
* backup;
* retention policies. '''Overengineering''' — надмірно складна технічна архітектура для простої задачі. '''Big Ball of Mud''' — антипатерн, коли платформа не має зрозумілої структури. * вимоги;
* обмеження;
* інтеграції;
* технології;
* security;
* cost;
* scalability;
* support;
* deployment;
* risks;
* trade-offs;
* compatibility із наявними системами.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>
'''Практична думка:''' технічна архітектура MVP має допомогти оперативно вчитися, але не створити технічну пастку вже на старті. '''Strangler Fig Pattern''' — підхід до поступової заміни legacy-системи. технічна архітектура має відповідати бізнес-цілям.</div>

'''Практична роль:''' API — це архітектурний контракт. Компоненти можуть:
Недоліки:
</div>

</div>

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

технічна архітектура складається з рішень.<div style="background:#e8f8f5; border-left:6px solid #16a085; padding:12px; margin:12px 0;">

* публікувати events;
* підписуватися на events;
* опрацьовувати events asynchronously;
* реагувати без прямого виклику іншого сервісу. * оптимізація читання;
* складні доменні сценарії;
* різні моделі для різних задач;
* корисно з event-driven systems. Корисні речі:

* які основні компоненти системи;
* хто за що відповідає;
* як компоненти взаємодіють;
* де зберігаються інформаційні дані;
* як платформа обробляє помилки;
* як функціонує authentication і authorization;
* як платформа масштабується;
* як її тестувати;
* як її розгортати;
* як її моніторити;
* як змінювати без хаосу. * Матеріали щодо monolith, modular monolith, microservices, layered architecture, clean architecture, hexagonal architecture і event-driven architecture. '''Solution architecture''' — технічна архітектура конкретного рішення для бізнесу для конкретної бізнес-задачі.== Enterprise Architecture ==

* вимоги;
* альтернативи;
* ризики;
* security;
* scalability;
* data model;
* operations;
* cost;
* migration plan;
* rollback;
* observability;
* compatibility;
* impact на команду. Його потрібно обирати під проблему, а не під моду.</div>
'''критично:''' спрощення архітектури — це не крок назад. рішення для бізнесу

Добра технічна архітектура часто навпаки виглядає нудно: зрозумілі модулі, передбачувані межі, очевидні залежності, нормальні логи, простий deployment і документація, яку справді читають. Недоліки:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

конкурентні переваги:

Важливі якості:

'''Найлюдяніший принцип:''' технічна архітектура, яку команда не здатна підтримувати, виступає як поганою архітектурою, навіть якщо вона виглядає правильно в книжці. * не переписувати все одразу;
* винести нову функціональність поруч;
* перенаправляти частину трафіку;
* поступово замінювати старі частини;
* зменшувати legacy step by step. - Authentication provider
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

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

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

</div>

* servers;
* containers;
* Kubernetes;
* load balancers;
* networking;
* DNS;
* storage;
* secrets;
* CI/CD;
* monitoring;
* logging;
* backups;
* disaster recovery;
* firewalls;
* cloud accounts;
* environments. - Monitoring
== Backend Architecture ==
== CQRS ==

Приклади подій:

'''Data architecture''' описує, як інформаційні дані збираються, зберігаються, обробляються, передаються й захищаються.== технічна архітектура і legacy ==

* слабше зв’язування компонентів;
* добра основа для async workflows;
* легше додавати нові реакції;
* корисно для масштабних систем. '''Помилка:''' хороша технічна архітектура не дорівнює максимальній складності.{{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 плану
}}

Хороша технічна архітектура не обов’язково складна.</div>
Команда використовує strangler fig pattern, поступово переносить частини системи в нові модулі або сервіси, не зупиняючи бізнес-середовище. '''Практична роль:''' технічна архітектура має масштабувати не тільки комп’ютери, а й людей. * менше адміністрування серверів;
* autoscaling;
* pay-per-use у частині сценаріїв;
* швидкий старт;
* добра інтеграційні функції ERP з cloud events.</div>

* retries;
* timeouts;
* idempotency;
* error handling;
* authentication;
* rate limits;
* monitoring;
* data mapping;
* contract changes.</div>

платформа зберігає історію:

'''Практична роль:''' reliable system не обов’язково ніколи не падає. Хороший моноліт здатна бути дуже ефективною архітектурою. * 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. * 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. * Практики application architecture, cloud architecture і enterprise architecture.<div style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

* добре тестується;
* бізнес-логіка менше залежить від framework;
* легше міняти infrastructure;
* корисна для складних доменів.</div>
Agile не означає відсутність архітектури. '''критично:''' технічна архітектура, яку важко розгортати, буде гальмувати ERP-продукт навіть із хорошим кодом.</div>

== Приклади сценаріїв використання ==

Context: Need relational data model and transactions

* зрозумілої структури;
* модульності;
* тестів;
* документації;
* code review;
* простих залежностей;
* хороших назв;
* стабільних API;
* низького coupling;
* контрольованого technical debt. + Clear internal boundaries
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">

Consequences: Strong SQL and ACID, but need DBA knowledge and backup strategy

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

* vertical scaling;
* horizontal scaling;
* database scaling;
* caching;
* read replicas;
* sharding;
* asynchronous processing;
* CDN;
* autoscaling;
* load balancing. Cloud architecture здатна включати:
</div>

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

</div>

'''Security architecture''' описує, як платформа захищає користувачів, інформаційні дані, інфраструктуру й бізнес-процеси. Вона охоплює:

== Security Architecture ==

* CI/CD;
* automated testing;
* infrastructure as code;
* containers;
* environment parity;
* rollback;
* monitoring;
* logging;
* deployment frequency;
* incident response;
* runbooks. Важливі фактори:

* модулі;
* сервіси;
* шари;
* API;
* бази даних;
* черги;
* кеші;
* інтеграції;
* deployment;
* security;
* scalability;
* observability;
* reliability;
* development workflow.<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
User Browser
Поширені architectural patterns:

</div>

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

== Data Architecture ==

* 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 style="background:#e7f3ff; border-left:6px solid #2b7cff; padding:12px; margin:12px 0;">

== технічна архітектура і масштабування команди ==

</div>

* web browser;
* mobile app;
* desktop app;
* CLI tool;
* IoT device.<syntaxhighlight lang="text">

* незалежний deployment;
* scaling окремих сервісів;
* технологічна гнучкість;
* автономія команд;
* краща ізоляція доменів.== Типові помилки початківців ==

* REST controller;
* database repository;
* message queue consumer;
* payment gateway adapter;
* email adapter;
* CLI adapter;
* test adapter. * зрозуміла структура;
* проста для навчання;
* добре підходить для багатьох CRUD-застосунків;
* легше розділяти відповідальність;
* зручна для командної роботи. * REST;
* GraphQL;
* gRPC;
* WebSocket;
* event APIs;
* webhooks;
* SOAP у legacy-системах. Насправді вона змінюється разом із продуктом. Часто це ознака зрілості. Не кожному застосунку потрібна технічна архітектура рівня глобального банку.== технічна архітектура і Agile ==

PaymentRequested

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

C4 оптимізує показати систему різним аудиторіям:

* використовувати 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.== технічна архітектура і бізнес-середовище ==

Decision:
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">
Observability містить:
== Цікаві факти про Architecture ==
<div style="background:#fff4e5; border-left:6px solid #f39c12; padding:12px; margin:12px 0;">
</div>

!== Приклад ADR ==
'''критично:''' технічна архітектура даних часто визначає майбутнє продукту сильніше, ніж вибір frontend framework. Де зберігаються інформаційні дані? Ознаки:

* REST API;
* webhooks;
* message queues;
* file exchange;
* ETL;
* event streaming;
* database replication;
* third-party SDK;
* enterprise service bus;
* iPaaS. Воно знає тільки порти. технічна архітектура застосовується для в багатьох сферах:
Backend API

 ↓

- Serverless-only architecture

Яке очікуване навантаження?</div>
=== Модернізація legacy ===
</div>

'''Головна перевага:''' хороша технічна архітектура зменшує вартість змін. '''Architecture review''' — перевірка важливого рішення для бізнесу або дизайну перед реалізацією. Погана технічна архітектура здатна бути як занадто хаотичною, так і занадто “розумною” без реальної потреби. Спочатку потрібно знайти реальне bottleneck.</div>
<div style="background:#f0eaff; border-left:6px solid #8e44ad; padding:12px; margin:12px 0;">
<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

== Big Ball of Mud ==

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

'''Критично:''' underengineering здатна оперативно дати MVP, але якщо ERP-продукт виживе, команда почне платити відсотки по технічному боргу. ↓
== Frontend Architecture ==
'''критично:''' висока availability коштує грошей і складності. '''CQRS''' або '''Command Query Responsibility Segregation''' — патерн, який розділяє операції запису й читання. OrderCreated

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

Практична роль: strangler pattern оптимізує модернізувати стару систему без ризикового “big bang rewrite”. * Найважчі архітектурні рішення для бізнесу часто стосуються даних, а не коду.=== Стартап MVP === критично: інтеграції ламаються не тільки через код, а й через зміни API, мережу, ліміти, інформаційні дані й людські процеси. технічна архітектура залежить не лише від технологій, а й від команди. Поганий моноліт — це хаос. Перевага

Agile architecture має бути:

ADR: Use modular monolith for first production version

Application Services

Інтеграції можуть бути через: Види масштабування:

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

Архітектурні якості

критично: event-driven architecture добре функціонує, коли команда розуміє асинхронність, повторну доставку, idempotency і спостережуваність. Помилка: думати, що технічна архітектура — це те, що роблять один раз на старті.

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

критично: патерн — це не наказ, а інструмент. OrderMarkedAsPaid

API;
business logic;
database access;
authentication;
authorization;
background jobs;
integrations;
caching;
queues;
transactions;
logging;
monitoring;
deployment. * Microservices часто вирішують організаційні проблеми не менше, ніж технічні. * schema design;
normalization;
indexes;
transactions;
replication;
partitioning;
backup;
migrations;
access control;
data retention;
audit logs;
read/write patterns;
consistency model. Якщо розбити хаос на 20 сервісів, вийде distributed chaos.

Client-server architecture — класична модель, де client надсилає запити, а server обробляє їх і повертає відповідь. технічна архітектура не виступає як без зусиль “красивою схемою”. ↓

Цікавий факт

починати із вимог і обмежень;
розуміти бізнес-цілі;
обирати найпростішу достатню архітектуру;
документувати важливі рішення для бізнесу через ADR;
малювати діаграми, які команда реально використовує;
планувати security з початку;
думати про observability;
мати backup і disaster recovery для важливих даних;
уникати premature microservices;
тримати модульні межі;
тестувати critical paths;
цифровізувати deployment;
вимірювати performance;
контролювати technical debt;
переглядати архітектуру з ростом продукту. Але коли з’являються нові функції, інтеграції, користувачі, помилки, команда й deadlines, погана структура починає “кричати”: зміни ламають інші частини, баги важко знайти, deployment страшний, а одна маленька правка займає тиждень. * Хороша технічна архітектура не завжди помітна користувачу, але користувач системи оперативно відчує її відсутність через помилки, повільність і нестабільність.

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

технічна архітектура здатна включати WebSocket gateway, message broker, cache, horizontal scaling і distributed tracing. Небезпечний борг — той, який ніхто не бачить. System architecture здатна включати:

</syntaxhighlight>

слабку документацію;
відсутні тести;
застарілі dependencies;
невідомі бізнес-правила;
manual deployment;
tight coupling;
погану observability;
важливі production-дані;
залежність бізнесу. Практична роль: технічна архітектура — це не лише технічне рішення для бізнесу.

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

Microservices Architecture

окремі codebases;
окремі deployments;
власні бази даних;
незалежні команди;
API contracts;
service discovery;
observability;
distributed tracing;
message brokers. Architecture або технічна архітектура — це спосіб організації складної системи: її частин, зв’язків, правил, обмежень і ключових рішень.

versioning;
authentication;
rate limits;
pagination;
error format;
documentation;
backward compatibility;
idempotency;
observability;
security. Поганий контракт змушує страждати всі системи, які від нього залежать. Legacy system — це не без зусиль стара платформа. Головна думка: технічна архітектура — це не про модні діаграми. * зрозумілої структури;
базової безпеки;
backup;
logging;
простого deployment;
функції ERP змінювати код;
мінімальної документації;
тестів для критичних сценаріїв. Проста думка: Agile-архітектура — це не “архітектури немає”, а “технічна архітектура розвивається разом із продуктом”. Він обирає, які проблеми платформа готова прийняти. * clear module boundaries;
ownership;
API contracts;
coding standards;
shared libraries;
documentation;
test strategy;
deployment process;
architecture review;
platform team у великих організаціях.

DevOps пов’язує архітектуру з delivery, operations і reliability. конкурентні переваги:

Найпрактичніший критерій: якщо нова людина в команді не здатна зрозуміти систему за розумний час, maintainability слабка. * microservices для маленького MVP;

Kubernetes без потреби;
багато абстракцій без реальних сценаріїв;
складний event bus для простого CRUD;
десятки сервісів без команди DevOps;
надто складна CI/CD схема;
технічна архітектура “на майбутнє”, яке не настало.

PaymentReceived

Як робиться backup і restore? * технічна архітектура має масштабувати не лише трафік, а й команду, підтримку й бізнес-середовище. Практична роль: ADR пояснює не лише “що ми обрали”, а й “чому ми так зробили”. Trade-off — компроміс між перевагами й недоліками.

здатна стати надто механічною;
іноді створює зайві шари;
погано спроєктований service layer здатна перетворитися на “мішок логіки”. * починати з модної технології, а не з вимог;
робити microservices для маленького проєкту;
не думати про інформаційні дані;
ігнорувати security;
не мати backup;
не мати логів;
не документувати рішення для бізнесу;
створювати занадто багато абстракцій;
плутати архітектуру з папками в коді;
не враховувати команду;
копіювати архітектуру великої компанії для маленького продукту;
не планувати deployment;
не думати про rollback;
ігнорувати performance до першої аварії;
вважати, що діаграма автоматизовано означає хорошу систему. Вона має бути достатньою для задачі, зрозумілою для команди, чесною щодо trade-offs і готовою до змін. Небезпека: Big Ball of Mud часто з’являється не за один день, а через багато маленьких “потім приберемо”. Замість зберігати лише поточний стан:

Frontend Web App

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. * time to market;
cost of change;
reliability;
customer trust;
compliance;
scaling;
hiring;
operations cost;
vendor lock-in;
product flexibility;
risk management.

Найлюдяніший факт: хороша технічна архітектура — це не та, яка виглядає найрозумнішою на діаграмі, а та, з якою команда здатна спокійно працювати через рік. Які вимоги до безпеки? Без нього команда здогадується, а не знає. Типові шари: технічна архітектура має враховувати: Практична роль: ADR оптимізує майбутній команді зрозуміти контекст рішення для бізнесу, а не без зусиль бачити результат. Практична порада: не треба масштабувати все одразу. Це про рішення для бізнесу, які дозволяють системі жити, змінюватися й залишатися зрозумілою людям, які її будують. Основна ідея: технічна архітектура — це відповідь на питання: “Як платформа влаштована так, щоб її можна було будувати, змінювати, масштабувати й підтримувати?” Приклади:

Status: Accepted

API Architecture

достатньою для поточного етапу;
готовою до змін;
не надмірною;
підтриманою тестами;
зрозумілою команді;
документованою через важливі рішення для бізнесу;
пов’язаною з feedback. * overengineering;
занадто багато шарів;
передчасні microservices;
складна інфраструктура без потреби;
технічна архітектура відірвана від команди;
документація не відповідає реальності;
повільні рішення для бізнесу через бюрократію;
патерни заради патернів;
vendor lock-in без розуміння;
security і operations забуті;
архітектор не слухає розробників. У програмуванні технічна архітектура часто стає помітною саме тоді, коли вона погана. Критично: помилки в database architecture часто найдорожчі, бо інформаційні дані важче змінювати, ніж код. Коли команда росте, технічна архітектура має допомагати людям працювати паралельно. Часто краще стабілізувати, покрити тестами, документувати й поступово замінювати. Практична роль: infrastructure architecture відповідає на питання: “Де й як живе наша платформа?”

System Architecture

Приклади server:

Практична роль: observability — це світло в машинному відділенні. Requirements may change quickly. Якщо її не спроєктували свідомо, вона виникла випадково. * простіший deployment, ніж microservices;

зрозумілі межі;
менше network complexity;
легше тестувати;
можна поступово виділити сервіс, якщо справді потрібно;
підходить для середніх продуктів.

Software Architecture

Serverless architecture — підхід, у якому команда пише функції або сервіси, а платформа керує значною частиною серверної інфраструктури.

Infrastructure Architecture

Ознаки:

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

commands змінюють стан;
queries читають стан;
read model здатна відрізнятися від write model.== Scalability ==

Приклади client:

Основні конкурентні переваги:

Недоліки:

через Перевага: технічна архітектура користувачі можуть перетворити набір файлів, сервісів і баз даних на систему з правилами, межами й зрозумілою логікою. Underengineering — недостатня архітектурна увага, коли платформа росте без структури.== Database Architecture ==

критично: застаріла архітектурна документація здатна бути небезпечнішою за її відсутність, бо створює фальшиве розуміння системи. Архітектуру оцінюють не лише за функціями, а й за якісними характеристиками. * Матеріали щодо architecture decision records, C4 model, domain-driven design, technical debt і software maintainability.

Практична роль: cloud architecture — це не без зусиль “перенести сервер у хмару”, а використати хмарні сервіси так, щоб платформа була надійною, безпечною й керованою за вартістю. Як функціонує rollback? Enterprise architecture описує технологічну й бізнесову структуру великої організації. Недоліки:

Maintainability — здатність системи швидко підтримувати й змінювати. * presentation layer;

application layer;
domain layer;
data access layer;
infrastructure layer. Часто найкраща технічна архітектура — найпростіша, яка чесно закриває вимоги. Вона містить:

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

Observability — здатність розуміти, що відбувається всередині системи, за зовнішніми сигналами. - CI/CD pipeline

== Performance ==

Для MVP технічна архітектура має бути простою, але не безвідповідальною. Integration architecture описує, як платформа взаємодіє з іншими системами. SOA часто асоціюється з: Небезпека: найгірша технічна архітектура часто виглядає дуже “професійно” на старті, але не відповідає реальним людям, бюджету й задачі. Найпрактичніший факт: modular monolith часто виступає як кращим першим вибором, ніж microservices, якщо команда ще не має реальної потреби в розподіленій архітектурі. Scalability — здатність системи витримувати зростання навантаження.== Приклад простої web architecture ==

складніше debug;
eventual consistency;
потреба в message broker;
duplicate events;
ordering problems;
складніша observability. Service-Oriented Architecture або SOA — підхід, у якому платформа складається з сервісів, що надають бізнес-функції через стандартизовані інтерфейси. Вона описує компоненти, їхні зв’язки, принципи організації, технологічні рішення для бізнесу й важливі trade-offs. Performance залежить від:

Decision: Use PostgreSQL </syntaxhighlight>

Layered Architecture

Типова application architecture здатна мати:

presentation layer;
application layer;
domain layer;
infrastructure layer;
database layer;
API layer;
integration layer;
background workers;
cache;
monitoring. Це платформа, яку важко змінювати без ризику. Core logic не знає деталей PostgreSQL, Stripe, HTTP або RabbitMQ. Архітектурне мислення потрібне, коли:

Overengineering

Проста різниця: enterprise architecture дивиться на всю організацію, а solution architecture — на конкретне рішення для бізнесу в межах цієї організації.== Тематичні мітки ==

Практична роль: enterprise architecture оптимізує великій компанії не перетворити сотні систем на некерований клубок інтеграцій. Architecture — це структура й логіка організації системи.

Архітектурний борг виникає через: Monolithic architecture — підхід, у якому застосунок розгортається як один базовий блок. * складніша мережа;

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

enterprise systems;
service contracts;
ESB;
SOAP у legacy-сценаріях;
integration platforms;
reusable business services;
governance. У software engineering вона визначає, як компоненти взаємодіють, де живуть інформаційні дані, як працюють API, security, deployment, monitoring, scalability і технічна підтримка.

'''Infrastructure architecture''' описує середовище, в якому функціонує застосунок. Він означає, що технічна архітектура здатна розвиватися поступово. '''Layered architecture''' або багатошарова технічна архітектура розділяє систему на шари. Ідея:

Backup

'''критично:''' frontend — це не “без зусиль кнопки”. Context:

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

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

 ↓

* logs;
* metrics;
* traces;
* alerts;
* dashboards;
* health checks;
* audit logs;
* error tracking;
* distributed tracing;
* business metrics. * Практики DevOps, CI/CD, observability, reliability engineering, security architecture і data architecture. '''Technical debt''' — наслідок рішень, які спрощують життя зараз, але можуть ускладнити майбутні зміни.</div>

* cold starts;
* vendor lock-in;
* складніше локальне тестування;
* обмеження runtime;
* складніша observability;
* не всі workloads підходять. Як вона розгортається?== Архітектурні патерни ==

* складність;
* versioning подій;
* storage growth;
* складніший debugging;
* потреба в сильній дисципліні. Ознаки:
== Architecture Decision Record ==

!== Solution Architecture ==
== Хороші практики архітектури ==
'''Backend architecture''' описує серверну частину застосунку.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

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

Потрібні integration architecture, data governance, security policies, audit logs, high availability, compliance і технічна підтримка legacy-систем. Ідея:

* складніше розділяти відповідальність при рості;
* великий codebase здатна стати важким;
* deployment усієї системи для однієї зміни;
* ризик сильного coupling;
* складніше масштабувати окремі частини. * повна історія продукту змін;
* auditability;
* можливість rebuild state;
* корисно для складних доменів.== Underengineering ==
</div>
== технічна архітектура і DevOps ==

</div>

Що буде складно змінити пізніше? * functions as a service;
* managed databases;
* object storage;
* event triggers;
* API gateway;
* queues;
* scheduled jobs;
* managed authentication. '''Практична порада:''' моноліт не виступає як поганим словом. * component structure;
* state management;
* routing;
* design system;
* API layer;
* forms;
* validation;
* caching;
* error handling;
* accessibility;
* performance;
* build tools;
* testing. Вона описує, як організовані frontend, backend, інформаційні дані, бізнес-логіка, API, authentication, background jobs і deployment. '''Найлюдяніший факт:''' технічна архітектура — це спосіб домовитися з майбутнім: “Ми знаємо, що все зміниться, тому будуємо так, щоб ці зміни нас не зламали”. У технічна архітектура передбачено multi-tenant data model, billing, authentication, role-based access control, background jobs, monitoring і CI/CD. Consequences:

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

* бізнес-процеси;
* application portfolio;
* data flows;
* integration landscape;
* security policies;
* compliance;
* governance;
* legacy systems;
* cloud strategy;
* identity management;
* enterprise platforms;
* technology standards;
* roadmaps. '''Практична роль:''' backend architecture визначає, наскільки надійно застосунок обробляє інформаційні дані, правила й інтеграції.<div style="background:#eafaf1; border-left:6px solid #2ecc71; padding:12px; margin:12px 0;">

Title: Use PostgreSQL as primary database

Client-Server Architecture