Словник архітектурних шаблонів програмного забезпечення: визначення і використання в контексті
Ключовий англійський словник для обговорення архітектури програмного забезпечення — моноліт, мікросервіси, CQRS, пошук подій, обмежений контекст і багато іншого, з прикладами використання для зустрічей і документації з розробки.
Обговорення архітектури програмного забезпечення мають щільний технічний словник, який нерідні носії англійської часто стикаються, перш ніж вони повністю засвоїли, як * використовувати * терміни природно в розмові. Знання визначення «CQRS» і можливість сказати «ми повинні розглянути застосування CQRS до обслуговування замовлень» на зустрічі з проектуванням є двома різними навичками. Цей підручник містить вісім основних термінів архітектури з визначеннями, контекстом і прикладними реченнями для використання у технічних обговореннях і документації.
1. моноліт
Definition
** Моноліт ** (або ** монолітна архітектура **) є єдиним розгорнутим блоком, який містить всі функціональні можливості програми — інтерфейс користувача, бізнес- логіку і шар доступу до даних, які упаковуються і розгортаються разом. Це типова початкова точка для більшості програм.
Використання нотаток
«Моноліт» часто використовується описово (нейтрально) або у псівському сенсі (наголошуючи, що система стала занадто великою, щоб легко керувати). Контекст имеет значение.
Приклади висловлювань
- «Поточна система є ** монолитом ** — всі служби мають одну базу даних і розгортаються як один блок. »
- «Перед тим, як ми обговоримо розділення цього на мікросервіси, давайте будемо чесними про те, чи ** моноліт ** насправді викликає у нас проблеми.»
- «Ми працюємо над модульним монолитом — код організований у чіткі модулі, але він все ще розгортається як єдиний артефакт»
- «Аргументом на користь модульного монолита є те, що його простіше експлуатувати і зневаджувати в нашому поточному масштабі»
Мікросервіси
Definition
Архітектура ** мікросервісів ** розкладає програму на невеликі, незалежно розгорнуті сервіси, кожен з яких відповідає за певні можливості бізнесу. Кожна служба працює у власному процесі і комунікує через мережу, зазвичай через HTTP або повідомлення.
Використання нотаток
Мікросервіси часто обговорюються разом з їхніми компромісами — збільшенням операційної складності, затримкою мережі і проблемами розподілених систем.
Приклади висловлювань
- «Ми розклали платформу на мікросервіси — кожен домен (платежі, запаси, доставка) є незалежним розгортанням»
- «Перехід до мікросервісів дав нам незалежність розгортання, але ми повинні були значно інвестувати в спостережність і оркестрацію сервісів»
- «Для команди з п’яти інженерів, я б поставив під сумнів, чи є ** архітектура мікросервісів ** правильним вибором на цьому етапі»
- «Сервіс платежу є нашим найкритичнішим мікросервісом — він має власну базу даних і власний цикл випуску»
3. Сервісна мережа
Definition
Service mesh є шаром інфраструктури, який обробляє комунікацію між службами в архітектурі мікросервісів. Він управляє такими проблемами, як балансування навантаження, виявлення сервісу, повторні спроби, розрив схеми, взаємний TLS і спостережність - зазвичай без змін коду програми.
Приклади висловлювань
- «Ми оцінюємо, чи ввести сервісну мережу — це дасть нам управління трафіком і взаємний TLS між службами без змін на рівні застосунків»
- “service mesh обробляє наші правила повторних спроб — окремі служби не повинні реалізовувати цю логіку самі.”
- «Один з аргументів проти сервісної мережі в нашому масштабі є операційна складність управління проксі-серверами»
4-й. Гексагональна архітектура (порти і адаптери)
Definition
** Шестикутна архітектура **, також відома як ** порти і адаптери **, є шаблоном проектування, який ізолює основну логіку програми від зовнішніх систем (баз даних, API, інтерфейсів користувача) за допомогою визначених інтерфейсів (портів) і взаємозамінних реалізацій (адаптерів). Метою є зробити основну логіку перевіреною і незалежною від проблем з інфраструктурою.
Використання нотаток
Цей шаблон часто обговорюється в контексті тестованості і чистої архітектури.
Приклади висловлювань
- «Ми структурували сервіс навколо ** гексагональної архітектури ** — логіка домену не залежить від бази даних безпосередньо; вона розмовляє з портом, а адаптер обробляє фактичну постійність.»
- «Однією з переваг портів і адаптерів є те, що ви можете обміняти базу даних на реалізацію в пам’яті в тестах без зміни основної логіки»
- “Гексагональна архітектура шаблон робить ясно, які частини кодової бази повинні бути ізольовані від інфраструктурних рішень.”
5-й. CQRS (Command Query Responsibility Segregation) — розділення відповідальності за запит
Definition
** CQRS ** відокремлює модель, яку використовують для оновлення стану (команд), від моделі, яку використовують для читання стану (запитів). Замість єдиної моделі, яка обробляє як читання, так і запис, у вас є окремі моделі — і часто окремі сховища даних — оптимізовані для кожної з цілей.
Використання нотаток
CQRS часто використовується разом з пошуком подій, і обговорення CQRS зазвичай включають обґрунтування доданої складності.
Приклади висловлювань
- «Ми застосовуємо CQRS до модуля звітів — модель читання є денормованою проекцією, оптимізованою для продуктивності запиту»
- “CQRS має найбільший сенс, коли шаблони читання і запису значно відрізняються - інакше складність може не бути виправданою.”
- «Сторіна запису використовує командну модель для перевірки і збереження бізнес-подій; сторона читання відновлює перегляд з цих подій»
- «Одним з викликів CQRS є забезпечення того, щоб модель читання залишалася послідовною з моделлю запису — особливо в системах з високою пропускною здатністю»
6. Пошук подій
Definition
** Визначення джерела подій ** — це шаблон, за якого стан програми визначається за допомогою послідовності незмінних подій, а не зберігається безпосередньо. Замість збереження поточного стану запису, ви зберігаєте журнал всіх подій, які призвели до цього стану, а поточний стан буде відновлено за допомогою повторення відтворення журналу подій.
Приклади висловлювань
- «Ми використовуємо event sourcing для обслуговування замовлень — кожна зміна стану (створена, оплачена, відправлена, скасована) зберігається як незмінна подія»
- «Походження подій дає нам повний аудиторський слід з коробки — ми можемо відновити стан будь-якого замовлення в будь-який момент часу»
- «Один компроміс з event sourcing полягає в тому, що запит на поточний стан вимагає відтворення подій, тому він часто поєднується з CQRS і моделлю читання»
- «Міграція існуючої системи до event sourcing не є тривіальною — набагато легше ввести її на початку нової служби.»
7. Можлива послідовність
Definition
** Послідовність можливих результатів ** — це модель послідовності, що використовується у розподілених системах, де після оновлення всі репліки даних * зрештою * зближаться до одного стану, але не існує гарантії негайної послідовності у всіх вузлах.
Використання нотаток
В кінцевому підсумку, послідовність контрастує з * сильною послідовністю * (всі читання повертають останній запис). Зрозуміти, коли прийняти кінцеву послідовність, є ключовим рішенням проектування.
Приклади висловлювань
- «Індекс пошуку працює за можливою послідовністю — може зайняти до 30 секунд, щоб новий продукт з’явився в результатах пошуку після його створення»
- “Ми прийняли можливу послідовність в цій частині системи в обмін на більшу доступність і пропускну здатність запису.”
- Важливо, щоб команда продукту розуміла модель можливої послідовності тут — користувачі можуть не побачити їх зміни відразу
- «Сильна послідовність доступна, але вартість затримки в цьому масштабі робить ** можливу послідовність ** правим компромісом для некритичних читання»
8. Обмежений контекст
Definition
** Обмежений контекст ** це концепція Domain-Driven Design (DDD), яка визначає явні межі, в межах яких певна модель домену є чинною і послідовною. Різні обмежені контексти можуть використовувати ті ж самі терміни з різними значеннями, і вони взаємодіють через добре визначені контракти.
Приклади висловлювань
- «Ми визначили три ** обмежені контексти ** в цьому домені: Замовлення, Виконання і Замовник. Вони мають окремі моделі і спілкуються через події»
- «Термін «клиєнт» означає щось інше в Billing ** обмежений контекст ** ніж в CRM — кожен має свою власну модель.»
- «Зберігаючи ** обмежені контексти ** окремо, стало набагато легше розвивати кожну службу незалежно.»
- «Інтеграція між ** обмеженим контекстом ** обробляється за допомогою спільного ядра і антикорупційних шарів.»
Архітектурний словник глосарій таблиця
| Term | One-Line Definition |
|---|---|
| Monolith | Single deployable unit containing all application functionality |
| Microservices | Decomposed, independently deployable services per business capability |
| Service mesh | Infrastructure layer managing service-to-service communication |
| Hexagonal architecture | Core logic isolated from infrastructure via ports and adapters |
| CQRS | Separate models for read and write operations |
| Event sourcing | State derived from a replay of immutable stored events |
| Eventual consistency | Distributed system model where replicas converge over time |
| Bounded context | DDD boundary within which a domain model is consistent and valid |
| Anti-corruption layer | Translation layer that prevents a legacy or foreign model from polluting a new model |
| Saga pattern | A way to manage distributed transactions across multiple services |
Ключеві моменти
- Словник з архітектури є найкориснішим, якщо ви знаєте не лише визначення, але і те, як ** використовувати термін у реченні ** під час зустрічі або у документі з проектування.
- Багато архітектурних шаблонів включають явні компроміси — названня компромісу («складність може не бути виправданою в нашому масштабі») сигналізує про архітектурну зрілість.
- Такі шаблони, як CQRS і пошук подій часто ** поєднуються ** - знання того, як вони пов’язані, дає вам більш плавну технічну розмову.
- ** Обмежений контекст ** є одним з найважливіших поняттів у проектуванні великомасштабних систем - він пояснює власність, термінологію та інтеграційні контракти.