Quick notes
Architecture judging
Based on the book (Balancing Coupling in Software Design). There are three axes of how to measure maturity of the modules:
Strength
how strong one module depends on another
API call -> weak coupling
Shared DB -> very strong coupling
Distance
how far are modules organised (and managed) from each other
In one deployment - > close
Different services -> futher
Different departments -> maximum distance
Volatility
How frequently and independently modules are changed.
Changed together -> high coupling
Each module lives independently -> low coupling
How to use it?
You make a table and check cooperation of modules based on three axes. If you see many "High" then think about changes.
module_1 -> module_2
High
High
High
👎
module_1 -> module_3
Low
High
Low
👍
Integrators and desintegrators
Дезинтеграторы — причины разделить систему:
Волатильность: часть часто меняется → выноси.
Масштабируемость: модуль нагружен → разнеси.
Отказоустойчивость: изоляция отказов → выделяй.
Безопасность: разные уровни доверия → изолируй.
Частота изменений: разные темпы → дели.
Расширяемость: если модуль растёт → вынеси.
Интеграторы — причины не разделять:
Общие транзакции (ACID).
Общий рабочий процесс (workflow).
Сильное статическое связывание (shared code).
Общие данные.
Сложная хореография.
Синхронные вызовы с общим SLA.
Мини-чеклист
Ты готов выделить сервис, если: ✅ У него отдельная зона ответственности ✅ Он живёт своей жизнью (волатильность, SLA) ✅ Его данные не нужны другим синхронно ✅ Он не участвует в общей транзакции ✅ Он даёт выигрыш, а не просто “ещё один сервис”
Ты НЕ готов, если: 🚫 У тебя будет shared DB 🚫 Без него нельзя обработать бизнес-флоу 🚫 У него жёсткая связка с другими по SLA 🚫 Каждый баг в нём ломает соседей
Last updated
Was this helpful?