Англійська мова для архітекторів розв'язків: Trade-off Language and Design Reviews

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

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

---

Основні завдання архітектора

1. Пропонування проекту — презентація нової системи, компонента або підходу
2. ** Документування компромісів ** — пояснення того, що було обрано, що було відхилено і чому
3. ** Запуск перегляду проекту ** — полегшення технічної критики і обговорення
4. Записання ADR — запис рішення для запису
5. Ескаляція ризику — перенесення технічного ризику на нетехнічне керівництво

---

Частина 1: Мова торгівлі

Архітектура ніколи не стосується пошуку ідеального рішення - це стосується вибору найкращого компромісу для контексту. Мова компромісів є найважливішим інструментом у словнику архітектора.

Основний словник компромісів

Term	Meaning
trade-off	A situation where gaining one property requires sacrificing another
constraint	A limitation that restricts the design space (budget, team size, existing systems)
driver	A factor that heavily influences the design decision
non-functional requirement (NFR)	A quality attribute: performance, availability, security, scalability, maintainability
quality attribute	Synonym for NFR — what “good” looks like beyond just “it works”
fitness for purpose	Whether a solution is appropriate for the specific context
coupled / decoupled	How much change in one component requires change in another
operability	How easy is the system to run in production?

Фрази для виразування компромісів

Визнать стоимость выбора:

• “Перевага X є Y, за рахунок Z.”
• “Цей підхід оптимізує для [доступності/затримки/послідовності], що означає прийняття [вищої вартості/збільшення складності/слабшої послідовності].”
• “Ми отримуємо [власність], але жертвуємо [власністю].”
• • “Це добре підходить, якщо [умова], але стає проблематичним, якщо [умова].” *

** Параметри порівняння: **

• • “Параметри А простіші з точки зору роботи, але вводять жорстке з’ єднання між [сервісами].” *
• • “Варіант B має більшу складність, але дає нам більше гнучкості, коли система зростає.” *
• “Обидва підходи є реалізовними - ключове питання полягає в тому, чи [умова X] важливіша за [умову Y] для цього контексту.”

** Пояснення, чому ви відхилили параметр: **

• “Ми розглядали [варіант], але відкинули його через [причину].”
• “[Параметр] міг би працювати, але він вимагав би [вартість/залежність/зміну], що не виправдано в цьому масштабі.”
• • “Головною проблемою з [параметр] є [зауваження]. Це не розрив угоди, але це стає значною відповідальністю, якщо [сценарій].”*

---

Частина 2: Дизайн перегляду мови

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

Відкривається перегляд проекту

“Дякую за створення цього. Перед тим, як ми займемось питаннями — чи можете ви дати нам 5-хвилинний огляд ключових рішень щодо дизайну і основних обмежень, з якими ви працювали?»

• “Я хотів би, щоб ми зосередилися на областях, де є найбільша невизначеність, — зокрема, [компонент X] і потік даних для [сценарій Y]. Чи це працює?»*

Задавати дослідні питання (не атакувати)

• • « Що станеться з [компонентом X] при [сценарії невдачі]?» *
• “Ви розглядали ситуацію, де [країнний випадок]?”
• “Яка очікувана [затримка/пропускна здатність/рівень помилок] під час [пікової навантаження]?”
• • « Як це взаємодіє з [існуючою системою]? » *
• “Що ми припускаємо про [зовнішню залежність], що може не мати місця?”
• • “Як виглядає відновлення, якщо нам потрібно повернути це?” *

Конструктивне повідомлення про зауваження

• • “Я маю зауваження щодо [X]. В частности, [объяснить беспокойство]. Я не кажу, що це блокатор — я хочу зрозуміти, чи [припущення] вірно.»*
• “Здається, що у нього можуть бути проблеми з [масштабуванням/операційними/з’єднаннями], якщо [стан]. Чи я щось пропустив?»
• “Дизайн має сенс для щасливого шляху. Моє питання стосується [режиму невдачі] — як ми з цим справляємося?»
• “Я б трохи відступив від [рішень]. Моя інтуїція - [альтернативне], тому що [причина]. Що змусило вас обрати [рішень] над цим?»

Досягнення консенсусу в перегляді дизайну

• • “Я думаю, що ми досягли широкої згоди щодо [X]. Останнє відкрите питання — [Y]. Чи можемо ми дати 10 хвилин, щоб розв’язати це?»*
• • “Це судовий виклик між [варіант А] і [варіант Б]. Обоє захищені. Хто має найсильнішу думку?»*
• “Моя рекомендація буде [рішень], але я хочу почути від [команда/особа] з огляду на їх досвід з [відповідною областю] перед тим, як ми зобов’ язуємося.”

---

Частина 3: Архитектурні рішення (ADRs)

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

Шаблон ADR

# ADR-042: Use Event Sourcing for the Orders Service

**Status:** Accepted  
**Date:** 2026-03-15  
**Authors:** [name(s)]  
**Reviewers:** [name(s)]  

---

## Context

The orders service currently stores only the current state of each order. 
As the business has grown, three problems have emerged:

1. We cannot reconstruct the history of how an order reached its current state 
   (needed for dispute resolution and compliance audits).
2. Multiple services need to react to order state changes, and our current 
   approach uses polling, which creates lag and load.
3. Debugging production issues requires manual log correlation, which is slow.

---

## Decision

We will adopt event sourcing for the orders service. All state changes will be 
persisted as immutable events to an event store. The current state of any order 
will be derived by replaying the relevant events.

---

## Alternatives Considered

**Option 1: Add an audit log table (rejected)**  
We could add a separate audit table that records all changes as a side effect. 
This solves the history requirement but does not address the event-driven 
integration or debugging problems. It also creates a dual-write consistency risk.

**Option 2: Continue with the current approach and add CDC**  
Change Data Capture on the database would allow other services to react to 
changes. This has lower implementation cost but ties event semantics to database 
schema changes, creating high coupling between internal implementation and the 
event contract.

**Option 3: Full Event Sourcing (accepted)**  
The event log becomes the source of truth. Read models are built as projections 
over the event log. This is more complex to implement but solves all three 
problems and positions us well for future requirements.

---

## Consequences

**Positive:**
- Complete order history available for compliance and dispute resolution.
- Clean event contract for downstream services to consume.
- Debugging becomes significantly easier — we can replay events to reproduce issues.

**Negative:**
- Eventual consistency for read models — queries may return slightly stale data.
  Acceptable given that order state is not required to be real-time for most reads.
- Increased initial implementation complexity (estimated +6 weeks for the 
  migration and new infrastructure).
- Team requires training on event sourcing patterns.

**Mitigations:**
- We will adopt a phased approach: new orders will use event sourcing; 
  existing orders will be migrated in a background job over 8 weeks.
- We will use [specific event store technology] which the team has prior 
  experience with.

---

## Review Notes

*[Space for comments from reviewers during the review process]*

---

Частина 4: Комунікація технічного ризику до керівництва

При представленні технічного ризику нетехнічному керівництву, вам потрібно перевести складність системи на мову бізнес-впливу.

Технічний ризик у бізнес-термінах

❌ “Якщо ми не звернемо увагу на проблему N + 1 запиту в службі користувача, база даних стане вузької ямкою в масштабі.”

✅ “Якщо ми зростаємо більше ніж 500 000 користувачів - що ми очікуємо досягти до Q3 - наша поточна архітектура, ймовірно, призведе до [повільного завантаження сторінок / перерви в роботі / підвищених витрат]. Ми можемо виправити це в 2 спринтах зараз, або зіткнутися з значно більшим виправленням під живим тиском руху пізніше. “

Формула комунікації ризику

1. Риск (просто сказано): “Що може піти не так?”
2. ** Тригер ** (коли це стає проблемою): * “На якому рівні/подія/дата це стає критичним?” *
3. Вплив (бізнес-мова): “Які наслідки для бізнесу?”
4. ** Вартість зменшення ризику ** (тепер проти пізніше): * “Скільки коштує виправити зараз проти розв’язання пізніше?” *
5. ** Рекомендація **: * “Що ви рекомендуєте нам зробити, і до якого часу?” *

Словник російської мови

• “Це прихована небезпека, яка виникне при [умові].”
• “Технический долг здесь управляемый сейчас, но значительно увеличивается, когда [фактор X] растет.”
• “Ми несем відомий ризик. Ймовірність — [низька/ середня/ висока]. Вплив, якщо він матеріалізується, це [опис].”
• “Це не блокувальник сьогодні, але він стане блокувальником у [масштаб/дата].”
• “У нас є вузьке вікно для вирішення цього питання до [подія/етап]. Після цього, ліквідація стало значно дорожче.»

---

Частина 5: РФК комунікація

Запит на коментарі (RFC) є відкритою пропозицією проекту, яка запрошує відгуки від команди перед тим, як буде прийнято рішення. Мова має бути запрошуючим, а не оборонним.

Шаблон введення RFC

# RFC: [Title of Proposed Change]

**Author:** [name]
**Status:** Open for comment  
**Discussion deadline:** [date]  
**Target decision date:** [date]

## Summary

One-paragraph description of what is being proposed and why.

## Motivation

What problem are we solving? Why now? What happens if we don't 
act on this?

## Proposal

The detailed proposed approach. Include diagrams if helpful.

## Open Questions

What are you still unsure about? What are the most important 
things you'd like feedback on?

1. [Question 1]
2. [Question 2]

## Alternatives Considered

What did you think about and reject, and why?

---

Словник скорочених назв

Situation	Phrase
Proposing a design	”My proposal is to… The key drivers behind this choice are…”
Presenting a trade-off	”This optimises for X at the cost of Y.”
Comparing options	”Both options are viable. The question is whether [A] or [B] matters more for our context.”
Flagging a risk	”I want to flag a concern about [X]. Specifically…”
Rejecting an option	”We considered [option] but ruled it out because…”
Acknowledging uncertainty	”This is our best understanding given current information. We’d revisit this as [condition] becomes clearer.”
Pushing back on a decision	”I’d push back slightly on [X]. My reasoning is [Y]. I’m open to being persuaded otherwise.”
Summarising consensus	”I think we have agreement on [X]. The open question is [Y].”

---

Зв’язані ресурси

• Як написати архітектурний запис рішення (ADR)
• Як не погоджуватися ввічливо в технічних зустрічах
• Програмне забезпечення: архітектура
• Англійська мова для перегляду коду